-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Implement -Zlink-directives=yes/no #107675
Conversation
r? @lcnr (rustbot has picked a reviewer for you, use r? to override) |
ad959f6
to
39c4b4f
Compare
Also cc @joshtriplett - I think I prefer this approach compared to raw_dylib since it can be controlled by the build system and doesn't need source changes. |
r? compiler |
I'm not sure if this is the approach we want long-term, but zero objection to it as a -Z flag for experimentation. |
56595ac
to
dd678f6
Compare
☔ The latest upstream changes (presumably #102963) made this pull request unmergeable. Please resolve the merge conflicts. |
dd678f6
to
bf9bee1
Compare
I've deployed this internally and it's already showing value - when importing third-party packages, we no longer need to edit the source to remove |
Seems fine to me. Perhaps we should proactively remove the other |
I'll put up a separate PR in case someone is still using it. |
Ping @wesleywiser. Or @joshtriplett is this something you could accept? |
👍 from me but I don't think I'm authoritative on compiler CLI arguments; someone from @rust-lang/compiler should r+ this. |
☔ The latest upstream changes (presumably #108301) made this pull request unmergeable. Please resolve the merge conflicts. |
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.
r=me after rebase, this looks good to me and it's an unstable flag so we don't need to pin down the final name or take a vote or anything.
`-Zlink-directives=no` will ignored `#[link]` directives while compiling a crate, so nothing is emitted into the crate's metadata. The assumption is that the build system already knows about the crate's native dependencies and can provide them at link time without these directives. This is another way to address issue # rust-lang#70093, which is currently addressed by `-Zlink-native-libraries` (implemented in rust-lang#70095). The latter is implemented at link time, which has the effect of ignoring `#[link]` in *every* crate. This makes it a very large hammer as it requires all native dependencies to be known to the build system to be at all usable, including those in sysroot libraries. I think this means its effectively unused, and definitely under-used. Being able to control this on a crate-by-crate basis should make it much easier to apply when needed. I'm not sure if we need both mechanisms, but we can decide that later.
bf9bee1
to
fde2e40
Compare
@davidtwco OK, I rebased and fixed the conflicts. |
@bors r+ |
…mpiler-errors Rollup of 7 pull requests Successful merges: - rust-lang#105736 (Test that the compiler/library builds with validate-mir) - rust-lang#107291 ([breaking change] Remove a rustdoc back compat warning) - rust-lang#107675 (Implement -Zlink-directives=yes/no) - rust-lang#107848 (Split `x setup` sub-actions to CLI arguments) - rust-lang#107911 (Add check for invalid #[macro_export] arguments) - rust-lang#108229 ([107049] Recognise top level keys in config.toml.example) - rust-lang#108333 (Make object bound candidates sound in the new trait solver) Failed merges: - rust-lang#108337 (hir-analysis: make a helpful note) r? `@ghost` `@rustbot` modify labels: rollup
I think we still need |
-Zlink-directives=no
will ignored#[link]
directives while compiling a crate, so nothing is emitted into the crate's metadata. The assumption is that the build system already knows about the crate's native dependencies and can provide them at link time without these directives.This is another way to address issue # #70093, which is currently addressed by
-Zlink-native-libraries
(implemented in #70095). The latter is implemented at link time, which has the effect of ignoring#[link]
in every crate. This makes it a very large hammer as it requires all native dependencies to be known to the build system to be at all usable, including those in sysroot libraries. I think this means its effectively unused, and definitely under-used.Being able to control this on a crate-by-crate basis should make it much easier to apply when needed.
I'm not sure if we need both mechanisms, but we can decide that later.
cc @pcwalton @cramertj