feature-gate #[must_use] for functions as fn_must_use#43776
feature-gate #[must_use] for functions as fn_must_use#43776bors merged 4 commits intorust-lang:masterfrom
fn_must_use#43776Conversation
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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 |
alexcrichton
left a comment
There was a problem hiding this comment.
Thanks! I wonder if it would be possible to gate as a "hard" error by default? That may help reduce the surrounding changes here!
There was a problem hiding this comment.
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