-
Notifications
You must be signed in to change notification settings - Fork 13.3k
feature-gate #[must_use] for functions as fn_must_use
#43776
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
// gate-test-fn_must_use | ||
|
||
#[must_use] | ||
fn use_it() -> bool { |
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.
The test is written wrongly, it should add an //~ ERROR #[must_use] on function is experimental
to one of these two lines (depends on which span is used to report the error).
// option. This file may not be copied, modified, or distributed | ||
// except according to those terms. | ||
|
||
// gate-test-fn_must_use |
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.
tidy error: /checkout/src/test/compile-fail/feature-gate-fn_must_use.rs:11: The file is already marked as gate test through its name, no need for a 'gate-test-fn_must_use' comment
☔ The latest upstream changes (presumably #43522) made this pull request unmergeable. Please resolve the merge conflicts. |
It's a breaking change -- Rust 1.19 thinks |
r? @rust-lang/libs |
The behavior as of the current revision of this pull request (Travis is currently failing because of tidy and the feature-gate test, but we can fix that after we understand what we want) would be the same with respect to allowing
@kennytm Are we allowed to make it a warning rather than a hard error? (To avoid it being a breaking change, see @bluss's comment.) |
A future-incompatible warning like E0122 can be issued. But that's up to the lang team to decide.
|
Thanks for the PR @zackmdavis! I think @kennytm's suggestions are all that's needed to land this! |
bad6afc
to
a937dca
Compare
(Updated—includes reworking some feature-gate functionality to be able to only emit a warning. On the other hand, if we decide we want a hard error (is there really going to be much code in the wild that has a |
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.
Thanks! I wonder if it would be possible to gate as a "hard" error by default? That may help reduce the surrounding changes here!
// below (which makes this compile-fail test fail) doesn't have anything to | ||
// do with the feature-gating, but pragmatically if awkwardly solves this | ||
// dilemma until a superior solution can be devised. | ||
== //~ ERROR expected expression |
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.
We also have #[rustc_error]
used throughout the test suite which may help here?
a937dca
to
398f414
Compare
Fine with me (pull request updated). A compatibility bullet point in the release notes seems appropriate, though. |
Oh oops sorry! I think I miscommunicated a bit. I think it's probably a good idea to avoid turning I wonder if perhaps though there's a more targeted way of "deprecating" the |
398f414
to
0f385f4
Compare
Oh, right. I did do some defaulting for the macros (which can be variadic), but I was trying to avoid too much code duplication. Looking at it today, I'm sure a much better trade-off between avoiding duplication and avoiding polluting existing |
Yeah the behavior of the current patch is fine by me, thanks! I'd just recommend a littl erefactoring to avoid needing to pass |
We'll actually want a new "soft" warning-only gate to maintain backwards-compatibility, but it's cleaner to start out with the established, well-understood gate before implementing the alternative warn-only behavior in a later commit. This is in the matter of rust-lang#43302.
The featureck.py that this comment referred to was removed in 9dd3c54 (March 2016).
8f6724b
to
6ca5490
Compare
Before `#[must_use]` for functions was implemented, a `#[must_use]` attribute on a function was a no-op. To avoid a breaking change in this behavior, we add an option for "this-and-such feature is experimental" feature-gate messages to be a mere warning rather than a compilation-halting failure (so old code that used to have a useless no-op `#[must_use]` attribute now warns rather than breaking). When we're on stable, we add a help note to clarify that the feature isn't "on." This is in support of rust-lang#43302.
This continues to be in the matter of rust-lang#43302.
6ca5490
to
35c4494
Compare
@alexcrichton updated (the only Travis subjobs that haven't passed yet are all macOS stuff) |
@bors: r+ |
📌 Commit 35c4494 has been approved by |
⌛ Testing commit 35c4494 with merge 1e20ae244f66a819647a597712fee38706ca1356... |
😪 I'm awake I'm awake |
@bors retry |
⌛ Testing commit 35c4494 with merge abd03494a40b02d6fa04f4cd1d025bb04423c61c... |
💔 Test failed - status-appveyor |
@bors retry rollup
|
…, r=alexcrichton feature-gate #[must_use] for functions as `fn_must_use` @eddyb I [was](rust-lang#43728 (comment)) [dithering](rust-lang#43728 (comment)) on this, but [your comment](rust-lang#43302 (comment)) makes it sound like we do want a feature gate for this? Please advise. r? @eddyb
I think this should be reverted: #44213 (comment) |
@eddyb I was dithering on this, but your comment makes it sound like we do want a feature gate for this? Please advise.
r? @eddyb