Repository navigation
Conversation
|
Some changes occurred in compiler/rustc_attr_parsing |
rustbot
added
A-attributes
|
r? @mu001999 rustbot has assigned @mu001999. Use Why was this reviewer chosen?The reviewer was selected based on:
|
|
This was previously cratered in #152856 (comment). That PR entirely removed |
JonathanBrouwer
added
T-lang
|
Given that the crater run only found 6 crates that this broke, I also wouldn't be against entirely removing the attribute immediately. What we want to do here is a @rust-lang/lang decision though, so lets let them decide |
This comment has been minimized.
This comment has been minimized.
|
I think it is polite to keep it as future incompat warning for a couple of releases. |
|
Blessed the tests and added #164032 as tracking issue. |
This comment has been minimized.
This comment has been minimized.
This is a pre-1.0 attribute that accidentally got stabilized. It was only meant for compiler plugins which we no longer support, not for regular crates. It is rather fragile and can easily lead to linker errors depending on where rustc decides to codegen functions and statics, which varies between rustc versions. It might also be unsound if a crate for example expects a global constructor it defined to run. Using it doesn't have an effect on the size of the produced binaries except when it defines a `#[used]` static given that we remove all unused functions and statics at link time already.
traviscross
added
I-lang-radar
| /// defined to run. Using it doesn't have an effect on the size of the produced | ||
| /// binaries except when it defines a `#[used]` static given that we remove all unused | ||
| /// functions and statics at link time already. | ||
| pub NO_LINK_ATTR_USED, |
There was a problem hiding this comment.
| pub NO_LINK_ATTR_USED, | |
| pub NO_LINK_ATTRIBUTES, |
Per our RFC 0344 guidance on pluralization, that our existing lints spell out attributes, and that the used part is implied, I'd suggest NO_LINK_ATTRIBUTES.
| Warn, | ||
| "detects usage of `#[no_link]` on `extern crate` items", | ||
| @future_incompatible = FutureIncompatibleInfo { | ||
| reason: fcw!(FutureReleaseError #164032), | ||
| }; |
There was a problem hiding this comment.
I think it is polite to keep it as future incompat warning for a couple of releases.
Do you want to make this a hard error after a couple of releases? If so, then it'd be better to propose this at deny-by-default and warn-in-deps (if the feeling is that this is sufficiently unused that it'd be OK to go straight to that). Otherwise, our normal practice would be, later, to first bump this to that, then to move to the hard error.
|
☔ The latest upstream changes (presumably #163235) made this pull request unmergeable. Please resolve the merge conflicts by rebasing. |
This branch has not been deployed
6 participants
This is a pre-1.0 attribute that accidentally got stabilized. It was only meant for compiler plugins which we no longer support, not for regular crates. It is rather fragile and can easily lead to linker errors depending on where rustc decides to codegen functions and statics, which varies between rustc versions. It might also be unsound if a crate for example expects a global constructor it defined to run. Using it doesn't have an effect on the size of the produced binaries except when it defines a
#[used]static given that we remove all unused functions and statics at link time already.