-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
RFC: #[used] static variables #2386
Conversation
While I know that C using I personally think that |
|
I'm inclined to merge -- this seems pretty low risk. If we come up with some other attribute that can serve this purpose, we can always deprecate |
I think the attribute should be renamed. I think a verb would fit Rust's naming conventions better instead of an adjective. My day job is mainly embedded development, and IAR's linker uses a |
Yes, "used" isn't the most straight-forward name. I personally prefer something like I'd rather have |
Deprecating just for the sake of name most likely won't ever happen, so if
we aren't content with the name the time to bikeshed is now.
I use both IAR and Linux toolchains and am more partial to GCC naming
convention, but admittedly #[used] clashes somewhat with #[must_use].
On Fri, Apr 13, 2018, 06:34 Michael Bradshaw <[email protected]>
wrote:
Yes, "used" isn't the most straight-forward name. I personally prefer
something like #[preserve(linker)] (with #[keep] as second(ish) choice; I
prefer to avoid negation where possible (e.g. #[no_remove])). The primary
benefit of the name #[used] is that it matches LLVM's and GCC's
__attribute__((used)). People familiar with LLVM's and GCC's attribute
should easily understand what #[used] does.
I'd rather have #[used] (as-is, with its current name) sooner rather than
bikeshed the name and delay its stabilization. I've got some code that's
raring to use it. A follow-up RFC could always introduce a new name (and
deprecate the "used" name).
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2386 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AApc0v4opUHRh3QE_VB0do9ig3knZdnQks5toBzNgaJpZM4TFjol>
.
On Apr 13, 2018 06:34, "Michael Bradshaw" <[email protected]> wrote:
Yes, "used" isn't the most straight-forward name. I personally prefer
something like #[preserve(linker)] (with #[keep] as second(ish) choice; I
prefer to avoid negation where possible (e.g. #[no_remove])). The primary
benefit of the name #[used] is that it matches LLVM's and GCC's
__attribute__((used)). People familiar with LLVM's and GCC's attribute
should easily understand what #[used] does.
I'd rather have #[used] (as-is, with its current name) sooner rather than
bikeshed the name and delay its stabilization. I've got some code that's
raring to use it. A follow-up RFC could always introduce a new name (and
deprecate the "used" name).
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2386 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AApc0v4opUHRh3QE_VB0do9ig3knZdnQks5toBzNgaJpZM4TFjol>
.
|
So, collecting what's proposed:
I would also propose |
@japaric We discussed this on the latest lang team meeting and the feeling was that |
I'm not part of the target user base, but I don't see a 9-character name like |
Discussed at the embedded-wg meeting, and #[link_keep] sounds fine. |
#[link_keep] says to me that this is something the link step (so, the
linker) should keep rather than something that should be kept intact until
linking.
…On Tue, Apr 24, 2018, 22:16 Jonathan Soo ***@***.***> wrote:
Discussed at the embedded-wg meeting, and #[link_keep] sounds fine.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2386 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AApc0uBBm6mkBuiiLtPCOOv9XruD3FJXks5tr3oZgaJpZM4TFjol>
.
|
To further elaborate: we are fine with any name. Personally, I'd rather not spend much time trying to find the "perfect" name. Very few people are going to directly deal with this feature; most people will depend on it because some crate in their dependency graph is using it. Some other people will indirectly use this feature behind a macro that ensures that's not misused ( Ultimately, I think the documentation is more important than the name of the feature and that's already covered by the RFC. All the suggested names sound fine to me; anyone will do, IMO. |
We briefly discussed this RFC in the last lang team meeting to generally positive response. We need to resolve the naming, but I'm going to go ahead and push toward FCP/full review: @rfcbot fcp merge |
Team member @aturon has proposed to merge this. The next step is review by the rest of the tagged teams: Concerns:
Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
@nagisa While that reading is possible, I think in this case,
|
I'm fine with (Edit: no longer fine with |
Let me elaborate on my comment. I’m a target audience for Even with good documentation, there’s a lot of value in concept having a self-descriptive name for people who are already familiar with said concept. So, even if somebody duckduckcame upon this attribute, without knowing about it a priori, it would require them to read through the whole documentation on the attribute to make sure it does what they want it to do. Lest they miss that extremely subtle distinction between attribute keeping items until or after linking (and they wanted the latter), they would spend a good few hours pondering why the attribute is “not working”. The name is outright confusing. I do agree that the attribute doesn’t need to be very terse, though, and thus |
@rfcbot concern attribute-name @nagisa That's a very good point! I hadn't thought about the potential implication there, but you're right, this doesn't affect the linker, it affects the compiler. That does make Given that, I'd personally favor I think this goes beyond bikeshedding, because there's a serious question here about compatibility (with widespread existing understanding) and descriptiveness (can we make something sufficiently more descriptive that it's worth not using the name "used" with all the understanding attached to that name). |
My 2 cents: While I don't have a strong opinion on the name, I tend to think that using a "familiar" name is a decent thing, in the absence of a strong alternative -- that is, I expect that most people who want this feature will go looking for it by asking "what is the equivalent to |
OK; So I was writing this comment about how That said, if Beyond this RFC, and on a tangent, @joshtriplett raised the idea on the lang meeting today of some more general mechanism by which you can search for an attribute via https://doc.rust-lang.org/nightly/std/?search=%23%5Bused%5D. cc @rust-lang/docs on that. |
@Centril Thanks for capturing that! I do think that'd be generally useful for things like "what do you call |
@joshtriplett At least for the "what's the trait associated with this operator", we've just gotten those added in thanks to rust-lang/rust#49757 and rust-lang/rust#50231. The issue for searching for specific attributes in the standard library docs is that most often there's no page for it to land on. The Reference is the better place for that. |
@QuietMisdreavus The reference is not searchable tho (can we change that?); Couldn't the standard library documentation simply take all attributes and link to the reference? |
|
Exactly. That's also consistent with GCC/LLVM: |
I have three issues with
Please consider my library example above. An I'm not against anything here in particular. I just see this moment as an opportunity to choose a better name. |
@rfcbot resolved attribute-name We discussed this in the lang team meeting, and ended up deciding to paint this bikeshed |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
I would use this annotation to prevent the optimizer from eliminating unused variables, so my proposal would be #[keep_unused] |
#[link_used] |
@frehberg That seems more like it would keep all unused variables. That might make Rust's 'unused variable' lint useless on statics. |
The final comment period, with a disposition to merge, as per the review above, is now complete. |
Huzzah! This RFC is merged! Tracking issue: rust-lang/rust#40289 |
I'm probably too late to chime in, but was |
@euclio Not a bad idea, but the |
Ah, I should've taken a look at the list of attributes. |
|
Yeah, imo it should definitely have link as part of the attribute somewhere
Liigo Zhuang <[email protected]> schrieb am Mi. 6. Juni 2018 um
05:13:
… #[used] is misleading. It's used until linking, but not used at writing
or compiling code.
should be #[to_be_used] or #[maybe_useful], or #[useful] for short?
useful also implies: compiler, don't dismiss this item, it's useful for
later use, i.e. linking.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2386 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABYmbjZbz4ucUETdD1FLR4skv7hql46Dks5t50jDgaJpZM4TFjol>
.
|
stabilize #[used] closes #40289 RFC for stabilization: rust-lang/rfcs#2386 r? @Centril Where should this be documented? Currently the documentation is in the unstable book
RFC to stabilize the experimental
#[used]
feature added in rust-lang/rust#39987.This feature has been in the compiler for a bit over a year; it's being widely used in embedded /
no-std context; and it has had no bugs filled against it (other than rust-lang/rust#41628 which was
filled shortly after the feature was added).
Tracking issue: rust-lang/rust#40289.
The embedded WG would like to see this feature stabilized in time for the edition release as it appears often in core components of the embedded ecosystem; it's not a blocker for the edition release though as it can be worked around.
Rendered
cc @aturon