-
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
Add --no-undefined-version
link flag and fix associated breakage
#108017
Conversation
r? @oli-obk (rustbot has picked a reviewer for you, use r? to override) |
r? @bjorn3 since we discussed this issue already |
/// `allocator_kind`, but it may return `None` in more cases (e.g. if using | ||
/// allocator definitions from a dylib dependency). | ||
query codegen_allocator_kind(_: ()) -> Option<AllocatorKind> { | ||
eval_always |
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.
This eval_always
can be removed as the query doesn't depend on untracked state but only on other queries (dependency_formats
and allocator_kind
). I'm not sure whether this makes sense to have as a query in the first place or whether it should just be a normal helper function. I think a normal function would make more sense as the output of this will usually change when the inputs (dependency_formats
and allocator_kind
) change and it's also pretty cheap to compute and only called twice.
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.
re: eval_always
: got it, I'm still getting to understand the query system.
A normal function would be fine, but there's some benefit of it being next to allocator_kind
too to potentially avoid similar mistakes in the future. Up to you though.
Any suggestion for where's a good place to put the helper function?
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.
Maybe compiler/rustc_codegen_ssa/src/base.rs? It doesn't quite fit, but I don't know a better place.
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, I moved the logic to a function there
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.
Sorry for the delay, I replied but didn't submit it
/// `allocator_kind`, but it may return `None` in more cases (e.g. if using | ||
/// allocator definitions from a dylib dependency). | ||
query codegen_allocator_kind(_: ()) -> Option<AllocatorKind> { | ||
eval_always |
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.
re: eval_always
: got it, I'm still getting to understand the query system.
A normal function would be fine, but there's some benefit of it being next to allocator_kind
too to potentially avoid similar mistakes in the future. Up to you though.
Any suggestion for where's a good place to put the helper function?
Hi, just checking in again |
b732615
to
332afdb
Compare
Ready for another review |
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.
LGTM, thanks! I got a minor request to avoid some code duplication, but r=me either way.
@rustbot author |
@bors delegate+ |
✌️ @chbaker0 can now approve this pull request |
ac58c9c
to
33e8820
Compare
Some changes occurred in compiler/rustc_codegen_cranelift cc @bjorn3 |
Thanks! @bors r+ extra changes are exactly as requested |
Makes sense; I guess I moved it under the appropriate condition. Not sure if the delegate earlier is sticky, but I'll try: @bors r+ |
🌲 The tree is currently closed for pull requests below priority 100. This pull request will be tested once the tree is reopened. |
Add `--no-undefined-version` link flag and fix associated breakage LLVM upstream sets `--no-undefined-version` by default in lld: https://reviews.llvm.org/D135402. Due to a bug in how version scripts are generated, this breaks the `dylib` output type for most crates. See rust-lang#105967 (comment) for details. This PR adds the flag to gcc flavor linkers in anticipation of this LLVM change rolling in, and patches `rustc` to not attempt to export `__rust_*` allocator symbols when they weren't generated. Fixes rust-lang#105967
Add `--no-undefined-version` link flag and fix associated breakage LLVM upstream sets `--no-undefined-version` by default in lld: https://reviews.llvm.org/D135402. Due to a bug in how version scripts are generated, this breaks the `dylib` output type for most crates. See rust-lang#105967 (comment) for details. This PR adds the flag to gcc flavor linkers in anticipation of this LLVM change rolling in, and patches `rustc` to not attempt to export `__rust_*` allocator symbols when they weren't generated. Fixes rust-lang#105967
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#105798 (Relax ordering rules for `asm!` operands) - rust-lang#105962 (Stabilize path_as_mut_os_str) - rust-lang#106085 (use problem matchers for tidy CI) - rust-lang#107711 (Stabilize movbe target feature) - rust-lang#108017 (Add `--no-undefined-version` link flag and fix associated breakage) - rust-lang#108891 (Remove an extraneous include) - rust-lang#108902 (no more do while :<) - rust-lang#108912 (Document tool lints) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Add `--no-undefined-version` link flag and fix associated breakage LLVM upstream sets `--no-undefined-version` by default in lld: https://reviews.llvm.org/D135402. Due to a bug in how version scripts are generated, this breaks the `dylib` output type for most crates. See rust-lang#105967 (comment) for details. This PR adds the flag to gcc flavor linkers in anticipation of this LLVM change rolling in, and patches `rustc` to not attempt to export `__rust_*` allocator symbols when they weren't generated. Fixes rust-lang#105967
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#105798 (Relax ordering rules for `asm!` operands) - rust-lang#105962 (Stabilize path_as_mut_os_str) - rust-lang#106085 (use problem matchers for tidy CI) - rust-lang#107711 (Stabilize movbe target feature) - rust-lang#108017 (Add `--no-undefined-version` link flag and fix associated breakage) - rust-lang#108891 (Remove an extraneous include) - rust-lang#108902 (no more do while :<) - rust-lang#108912 (Document tool lints) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
…proc-macros-issue-99978, r=bjorn3 Restrict linker version script of proc-macro crates to just its two symbols Restrict linker version script of proc-macro crates to just the two symbols of each proc-macro crate. The main known effect of doing this is to stop including `#[no_mangle]` symbols in the linker version script. Background: The combination of a proc-macro crate with an import of another crate that itself exports a no_mangle function was broken for a period of time, because: * In PR rust-lang#99944 we stopped exporting no_mangle symbols from proc-macro crates; proc-macro crates have a very limited interface and are meant to be treated as a blackbox to everything except rustc itself. However: he constructed linker version script still referred to them, but resolving that discrepancy was left as a FIXME in the code, tagged with issue rust-lang#99978. * In PR rust-lang#108017 we started telling the linker to check (via the`--no-undefined-version` linker invocation flag) that every symbol referenced in the "linker version script" is provided as linker input. So the unresolved discrepancy from rust-lang#99978 started surfacing as a compile-time error (e.g. rust-lang#111888). Fix rust-lang#111888 Fix rust-lang#99978.
LLVM upstream sets
--no-undefined-version
by default in lld: https://reviews.llvm.org/D135402.Due to a bug in how version scripts are generated, this breaks the
dylib
output type for most crates. See #105967 (comment) for details.This PR adds the flag to gcc flavor linkers in anticipation of this LLVM change rolling in, and patches
rustc
to not attempt to export__rust_*
allocator symbols when they weren't generated.Fixes #105967