Skip to content

support for GNU configure syntax - #9760

Closed
Cynede wants to merge 3 commits into
masterfrom
unknown repository
Closed

support for GNU configure syntax#9760
Cynede wants to merge 3 commits into
masterfrom
unknown repository

Conversation

@Cynede

Copy link
Copy Markdown
Contributor

Re-created: #9565

t will be useful for unix systems, some package managers and external tools that is passing / maybe looking for GNU configure syntax options.

One of related bugs: #5138

Also that could be useful in future if project will really install man pages / other stuff using those variables.

@pnkfelix

Copy link
Copy Markdown
Contributor

cc me

@brson

brson commented Oct 8, 2013

Copy link
Copy Markdown
Contributor

Oh sorry @Heather I missed your questions in the other PR. I think my previous comment explained more or less how to convert to the new variable names.

To make mandir do something useful you'll need to export CFG_MANDIR from configure using putvarhere. Then use that variable for copying the man pages in install.mk.

@Cynede

Copy link
Copy Markdown
ContributorAuthor

@brson thank you , I never used to work with hand-written configure scripts.

@adrientetar

Copy link
Copy Markdown
Contributor

Maybe old commands can be dropped as soon as the buildbots are edited to work with GNU commands?

@brson

Copy link
Copy Markdown
Contributor

@adridu59 yes

@Cynede

Copy link
Copy Markdown
ContributorAuthor

This pull request is ready / and waiting for review.

@Cynede

Copy link
Copy Markdown
ContributorAuthor

fork moved to Cynede organization

@brson

Copy link
Copy Markdown
Contributor

Besides my comment about the linux target triple, this looks great! Thanks for sticking with it. It does need a rebase now though.

@Cynede

Copy link
Copy Markdown
ContributorAuthor

@brson thank you, but one of #rust irc users was confused about renaming all CFG_***_TRIPLE to remove TRIPLE word, so I really hope it's fine thing to do.

Re-base is easy but separating unknown fix is a bit more of work ... I can do it but it will take some more time. Are you sure that it's not safe to replace unknown-lunux-gnu with pc-linux-gnu right now? Because at least mingw already on pc- and I don't get why linux is still being on unknown.

@Cynede

Copy link
Copy Markdown
ContributorAuthor

re-based.

@brson

Copy link
Copy Markdown
Contributor

Superseded by #9990

@brsonbrson closed this Oct 21, 2013
flip1995 pushed a commit to flip1995/rust that referenced this pull request Nov 21, 2022
Add new lint [`let_underscore_future`]
This closesrust-lang#9721
---
changelog: add new lint [`let_underscore_future`]
flip1995 pushed a commit to flip1995/rust that referenced this pull request Mar 10, 2023
Downgrade let_underscore_untyped to restriction
From reading rust-lang#6842 I am not convinced of the cost/benefit of this lint even as a pedantic lint.
It sounds like the primary motivation was to catch cases of `fn() -> Result` being changed to `async fn() -> Result`. If the original Result was ignored by a `let _`, then the compiler wouldn't guide you to add `.await`. **However, this situation is caught in a more specific way by [let_underscore_future](https://rust-lang.github.io/rust-clippy/master/index.html#let_underscore_future) which was introduced _after_ the original suggestion (rust-lang#9760).**
In rust-lang#10410 it was mentioned twice that a <kbd>restriction</kbd> lint might be more appropriate for let_underscore_untyped.
changelog: Moved [`let_underscore_untyped`] to restriction
U007D pushed a commit to U007D/rust-mos that referenced this pull request Aug 21, 2026
9764: fix: Don't use the module as the candidate node in fuzzy path flyimport r=Veykril a=Veykril
The problem was that the candidate node is whats being used for the scope, so using an inline module will yield the surrounding scope of the module instead of the scope of the module itself.
Also seems to fix the problem in this comment rust-lang/rust-analyzer#9760 (comment), though I could not recreate that in a test for some reason.
Fixesrust-lang#9760
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants

@Cynede@pnkfelix@brson@adrientetar