Skip to content
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

feature-gate #[must_use] for functions as fn_must_use #43776

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
Contributor

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
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
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
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
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
Contributor

bors commented Aug 23, 2017

📌 Commit 35c4494 has been approved by alexcrichton

@bors
Copy link
Contributor

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
Contributor

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
Contributor

bors commented Aug 24, 2017

⌛ Testing commit 35c4494 with merge abd03494a40b02d6fa04f4cd1d025bb04423c61c...

@bors
Copy link
Contributor

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in 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