Skip to content

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

Merged
merged 4 commits into from
Aug 26, 2017

Conversation

zackmdavis
Copy link
Member

@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

// gate-test-fn_must_use

#[must_use]
fn use_it() -> bool {
Copy link
Member

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
Copy link
Member

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

@aidanhs aidanhs added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Aug 10, 2017
@bors
Copy link
Collaborator

bors commented Aug 10, 2017

☔ The latest upstream changes (presumably #43522) made this pull request unmergeable. Please resolve the merge conflicts.

@bluss
Copy link
Member

bluss commented Aug 11, 2017

It's a breaking change -- Rust 1.19 thinks #[must_use] on a function is ok to compile.

@eddyb
Copy link
Member

eddyb commented Aug 11, 2017

r? @rust-lang/libs

@zackmdavis
Copy link
Member Author

Rust 1.19 thinks #[must_use] on a function is ok to compile.

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 #[must_use] on functions to compile, but the warning would only be emitted if the feature is enabled.

it should add an //~ ERROR #[must_use] on function is experimental

@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.)

@kennytm
Copy link
Member

kennytm commented Aug 11, 2017

@zackmdavis

A future-incompatible warning like E0122 can be issued. But that's up to the lang team to decide.

  • If fn_must_use is disabled, #[must_use] on function is no-op (allowed or future-incompatible-linted), and ignoring the return value will produce no lint.
  • If fn_must_use is enabled, #[must_use] on function does what we expected (allowed), and ignoring the return value will produce lint.

@alexcrichton alexcrichton self-assigned this Aug 11, 2017
@alexcrichton
Copy link
Member

Thanks for the PR @zackmdavis! I think @kennytm's suggestions are all that's needed to land this!

@zackmdavis zackmdavis force-pushed the feature_gate_fn_must_use branch 4 times, most recently from bad6afc to a937dca Compare August 16, 2017 04:35
@zackmdavis
Copy link
Member Author

(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 #[must_use] on a function even though it's currently a no-op?—does such silly code not deserve what it gets, or are our stability guarantees meant to be taken that literally?), a937dca could be excluded.)

Copy link
Member

@alexcrichton alexcrichton left a 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
Copy link
Member

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?

@zackmdavis zackmdavis force-pushed the feature_gate_fn_must_use branch from a937dca to 398f414 Compare August 16, 2017 17:00
@zackmdavis
Copy link
Member Author

I wonder if it would be possible to gate as a "hard" error by default?

Fine with me (pull request updated). A compatibility bullet point in the release notes seems appropriate, though.

@alexcrichton
Copy link
Member

Oh oops sorry! I think I miscommunicated a bit. I think it's probably a good idea to avoid turning #[must_use] on functions into hard errors immediately, what I meant was that instead of specifying Hard to all the gating invocations that was just done by default, but #[must_use] still generated warnings.

I wonder if perhaps though there's a more targeted way of "deprecating" the #[must_use] attribute on functions?

@zackmdavis zackmdavis force-pushed the feature_gate_fn_must_use branch from 398f414 to 0f385f4 Compare August 16, 2017 17:47
@zackmdavis
Copy link
Member Author

what I meant was that instead of specifying Hard to all the gating invocations that was just done by default

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 feature_err and emit_feature_err callsites with a new argument is possible. I'm out of town for a few days (RustConf!), but I can probably get to this on Monday?

@alexcrichton
Copy link
Member

Yeah the behavior of the current patch is fine by me, thanks! I'd just recommend a littl erefactoring to avoid needing to pass GateStrength::Hard so often, and other than that r=me!

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).
@zackmdavis zackmdavis force-pushed the feature_gate_fn_must_use branch 2 times, most recently from 8f6724b to 6ca5490 Compare August 23, 2017 02:30
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.
@zackmdavis zackmdavis force-pushed the feature_gate_fn_must_use branch from 6ca5490 to 35c4494 Compare August 23, 2017 03:40
@zackmdavis
Copy link
Member Author

@alexcrichton updated (the only Travis subjobs that haven't passed yet are all macOS stuff)

@alexcrichton
Copy link
Member

@bors: r+

@bors
Copy link
Collaborator

bors commented Aug 23, 2017

📌 Commit 35c4494 has been approved by alexcrichton

@bors
Copy link
Collaborator

bors commented Aug 24, 2017

⌛ Testing commit 35c4494 with merge 1e20ae244f66a819647a597712fee38706ca1356...

@kennytm
Copy link
Member

kennytm commented Aug 24, 2017

@bors ping

Hello, both Travis and AppVeyor have finished successfully but nothing happens?

@bors
Copy link
Collaborator

bors commented Aug 24, 2017

😪 I'm awake I'm awake

@kennytm
Copy link
Member

kennytm commented Aug 24, 2017

@bors retry

@bors
Copy link
Collaborator

bors commented Aug 24, 2017

⌛ Testing commit 35c4494 with merge abd03494a40b02d6fa04f4cd1d025bb04423c61c...

@bors
Copy link
Collaborator

bors commented Aug 24, 2017

💔 Test failed - status-appveyor

@kennytm
Copy link
Member

kennytm commented Aug 24, 2017

@bors retry rollup

frewsxcv added a commit to frewsxcv/rust that referenced this pull request Aug 26, 2017
…, 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
bors added a commit that referenced this pull request Aug 26, 2017
Rollup of 7 pull requests

- Successful merges: #43776, #43966, #43979, #44072, #44086, #44090, #44091
- Failed merges:
@bors bors merged commit 35c4494 into rust-lang:master Aug 26, 2017
@SimonSapin
Copy link
Contributor

I think this should be reverted: #44213 (comment)

@zackmdavis zackmdavis deleted the feature_gate_fn_must_use branch January 13, 2018 07:44
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants