-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rustc_target: Refactor internal linker flavors #101988
Conversation
|
db8e12d
to
9df08f0
Compare
This comment was marked as resolved.
This comment was marked as resolved.
(I've already started looking at this and will finish this weekend) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Woo! Thanks for starting to untangle the mess! Looks good overall, a couple small comments
| LinkerFlavor::Darwin(Cc::Yes, _) | ||
| LinkerFlavor::WasmLld(Cc::Yes) | ||
| LinkerFlavor::Unix(Cc::Yes) => LinkerFlavorCli::Gcc, | ||
LinkerFlavor::Gnu(_, Lld::Yes) => LinkerFlavorCli::Lld(LldFlavor::Ld), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Explicit Cc::No
here since that's what we want here semantically vs "anything"? Makes it a little more resilient in-case the match arms get moved around in the future. Similarly for Darwin
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That applies to Lld::No
too, so you'd have to fill in all the redundant info in variants below to stay consistent. My initial thought was to not fill the redundant info to make it shorter and do not distract attention from the "important" part.
} else if stem == "lld" || stem == "rust-lld" { | ||
LinkerFlavor::Lld(sess.target.lld_flavor) | ||
let lld_flavor = sess.target.linker_flavor.lld_flavor(); | ||
LinkerFlavor::from_cli(LinkerFlavorCli::Lld(lld_flavor), &sess.target) | ||
} else { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given we already have cases for ld.lld
, lld-link
and wasm-ld
is there any reason not to have one for ld64.lld
as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just didn't change any logic here, the linker name heuristic can be improved in multiple ways, e.g. accounting for cc
and c++
/g++
/clang++
as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, that was just a small thing I noticed while reading through that bit. More for completeness sake since I don't think i've seen any complaints about that case missing
LinkerFlavor::WasmLld(Cc::No) | ||
} else if stem == "ld" || stem.ends_with("-ld") { | ||
LinkerFlavor::from_cli(LinkerFlavorCli::Ld, &sess.target) | ||
} else if stem == "ld.lld" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Come to think of it, does this case even work as expected? file_stem
on ld.lld
would return ld
meaning we never take this branch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's reachable if it full file name was ld.lld.exe
:)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True but you'd think ld.lld
is a lot more common than ld.lld.exe
😛
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not impossible though!
we@we-pc MINGW64 ~
$ where ld.lld
C:\msys64\mingw64\bin\ld.lld.exe
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK that was a mouthful. It's unfortunate that lld is forcing our hand to make things more complex, but they're also sometimes simpler/clearer than today with the new explicitness (albeit also more verbose).
I left a couple comments in addition to Luqman's (and an if
that needs clarification or fixing), and with these done: r=me after rebase.
(Note that Github duplicated comments added to existing conversations when it posted the review, so they lost the context of what they're replying to, but that's present in the original conversations...) |
@rustbot author |
@bors r=lqd |
📌 Commit 708874a7f704c5f6e85cb65a4ba488d03ea5603d has been approved by It is now in the queue for this repository. |
⌛ Testing commit 708874a7f704c5f6e85cb65a4ba488d03ea5603d with merge 2a0993ab9e0963429b6f47804e74f8975ef0ea08... |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
In accordance with the design from rust-lang#96827 (comment)
Fixed an access to unsynchronized json fields in |
☀️ Test successful - checks-actions |
Finished benchmarking commit (cf0fa76): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Footnotes |
I believe that this change has broken the parsing of
I am unable to bisect the breakage down to a specific commit, but this is the only that changed relevant parts of the compiler between the two nightlies, and it seems that this change in particular would cause this breakage: rust/compiler/rustc_target/src/spec/mod.rs Lines 1743 to 1745 in cf0fa76
cf0fa76#diff-aa810a3be0834da891b171a8b04b09d0d3bbb76ac27c757cd232235099e062d2R1742 Is this intentional? If so, what's the new way of passing custom linker arguments via the target? |
@yuriks |
rustc_target: Fix json target specs using LLD linker flavors in link args Fixes rust-lang#101988 (comment) (a regression introduced by rust-lang#101988).
rustc_target: Fix json target specs using LLD linker flavors in link args Fixes rust-lang#101988 (comment) (a regression introduced by rust-lang#101988).
Revert to using latest nightly as the rust toolchain since the blocker issue (rust-lang/rust#101988 (comment)) has been resolved. Signed-off-by: Andy-Python-Programmer <[email protected]>
In accordance with the design from #96827 (comment)
lld_flavor
andlinker_is_gnu
fields are removed from internal target specs, but still parsed from JSON specs using compatibility layer introduced in #100552.r? @lqd