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

Tracking issue for RFC 1940: allow `#[must_use]` on functions #43302

Closed
aturon opened this Issue Jul 17, 2017 · 43 comments

Comments

Projects
None yet
@aturon
Copy link
Member

aturon commented Jul 17, 2017

This is a tracking issue for the RFC "allow #[must_use] on functions" (rust-lang/rfcs#1940).

Steps:

@zackmdavis

This comment has been minimized.

Copy link
Member

zackmdavis commented Aug 8, 2017

I think I should have an implementation shortly.

zackmdavis added a commit to zackmdavis/rust that referenced this issue Aug 8, 2017

#[must_use] for functions (RFC 1940)
The return values of a function annotated with `must_use`, must be used. We put
this behind a `fn_must_use` feature gate.

This is in the matter of rust-lang#43302.

zackmdavis added a commit to zackmdavis/rust that referenced this issue Aug 8, 2017

The return value of a function annotated with `must_use`, must be use…
…d. We put

this behind a `fn_must_use` feature gate.

This is in the matter of rust-lang#43302.

zackmdavis added a commit to zackmdavis/rust that referenced this issue Aug 8, 2017

mark comparison trait methods as #[must_use]
Note that this doesn't actually give us warnings on `a == b;` and the like, as
some observers may have hoped.

This is in the matter of rust-lang#43302.

zackmdavis added a commit to zackmdavis/rust that referenced this issue Aug 8, 2017

#[must_use] for functions (RFC 1940)
The return value of a function annotated with `must_use`, must be used. We put
this behind a `fn_must_use` feature gate.

This is in the matter of rust-lang#43302.

zackmdavis added a commit to zackmdavis/rust that referenced this issue Aug 8, 2017

mark comparison trait methods as #[must_use]
Note that this doesn't actually give us warnings on `a == b;` and the like, as
some observers may have hoped.

This is in the matter of rust-lang#43302.

zackmdavis added a commit to zackmdavis/rust that referenced this issue Aug 8, 2017

#[must_use] for functions (RFC 1940)
The return value of a function annotated with `must_use`, must be used. We put
this behind a `fn_must_use` feature gate.

This is in the matter of rust-lang#43302.

zackmdavis added a commit to zackmdavis/rust that referenced this issue Aug 8, 2017

mark comparison trait methods as #[must_use]
Note that this doesn't actually give us warnings on `a == b;` and the like, as
some observers may have hoped.

This is in the matter of rust-lang#43302.

zackmdavis added a commit to zackmdavis/rust that referenced this issue Aug 8, 2017

#[must_use] for functions (RFC 1940)
The return value of a function annotated with `must_use`, must be used.

This is in the matter of rust-lang#43302.

zackmdavis added a commit to zackmdavis/rust that referenced this issue Aug 8, 2017

mark comparison trait methods as #[must_use]
Note that this doesn't actually give us warnings on `a == b;` and the like, as
some observers may have hoped.

This is in the matter of rust-lang#43302.

bors added a commit that referenced this issue Aug 9, 2017

Auto merge of #43728 - zackmdavis:fnused, r=eddyb
#[must_use] for functions

This implements [RFC 1940](rust-lang/rfcs#1940).

The RFC and discussion thereof seem to suggest that tagging `PartialEq::eq` and friends as `#[must_use]` would automatically lint for unused comparisons, but it doesn't work out that way (at least the way I've implemented it): unused `.eq` method calls get linted, but not `==` expressions. (The lint operates on the HIR, which sees binary operations as their own thing, even if they ultimately just call `.eq` _&c._.)

What do _you_ think??

Resolves #43302.

@bors bors closed this in #43728 Aug 9, 2017

@crumblingstatue

This comment has been minimized.

Copy link
Contributor

crumblingstatue commented Aug 9, 2017

I'm just adding a note here that the current implementation of #1940 does not lint for unused ==, which was the main motivation for it.

In fact, the RFC itself states in the motivation

By marking PartialEq #[must_use] the compiler would complain about things like:

 modem_reset_flag == false; //warning
 modem_reset_flag = false; //ok
@zackmdavis

This comment has been minimized.

Copy link
Member

zackmdavis commented Aug 9, 2017

Yeah, that's a little awkward. I can add the comparison operators in a follow-on PR.

@eddyb

This comment has been minimized.

Copy link
Member

eddyb commented Aug 9, 2017

Also, this issue shouldn't have been closed. Ahhh I may have not checked for a feature gate in the implementation. I'm a bad reviewer.

@eddyb eddyb reopened this Aug 9, 2017

zackmdavis added a commit to zackmdavis/rust that referenced this issue Aug 16, 2017

zackmdavis added a commit to zackmdavis/rust that referenced this issue Aug 16, 2017

"soft" (warn instead of error) feature-gate for #[must_use] on functions
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. 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 added a commit to zackmdavis/rust that referenced this issue Aug 16, 2017

"soft" (warn instead of error) feature-gate for #[must_use] on functions
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. 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 added a commit to zackmdavis/rust that referenced this issue Aug 16, 2017

add comparison operators to must-use lint (under `fn_must_use` feature)
Although the RFC sanctions annotating functions with `#[must_use]`, a key part
of the motivation was linting unused comparison (especially equality)
operators.

This is in the matter of rust-lang#43302.
@zackmdavis

This comment has been minimized.

Copy link
Member

zackmdavis commented Aug 16, 2017

I have an implementation for linting == and the other comparison operators. (It's based off the feature-gating work, so we'll let that land first.)

zackmdavis added a commit to zackmdavis/rust that referenced this issue Aug 16, 2017

zackmdavis added a commit to zackmdavis/rust that referenced this issue Aug 16, 2017

zackmdavis added a commit to zackmdavis/rust that referenced this issue Aug 16, 2017

"soft" (warn instead of error) feature-gate for #[must_use] on functions
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. 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.
@oli-obk

This comment has been minimized.

Copy link
Contributor

oli-obk commented Mar 30, 2018

Clippy has a correctness lint for that: https://rust-lang-nursery.github.io/rust-clippy/master/index.html#unused_io_amount

I don't think it can be caught by must_use, but a targeted lint can.

@zackmdavis

This comment has been minimized.

Copy link
Member

zackmdavis commented Mar 30, 2018

Is there any issue that tracks which std APIs are going to have this annotation?

Please, contribute your thoughts on #48926.

@rfcbot

This comment has been minimized.

Copy link

rfcbot commented Apr 1, 2018

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot

This comment has been minimized.

Copy link

rfcbot commented Apr 11, 2018

The final comment period is now complete.

@TimNN

This comment has been minimized.

Copy link
Contributor

TimNN commented Apr 17, 2018

@nikomatsakis: It looks like it was decided to stabilize this, can I assume that #48925 is now un-blocked?

@nikomatsakis

This comment has been minimized.

Copy link
Contributor

nikomatsakis commented Apr 23, 2018

@TimNN yep

@zackmdavis

This comment has been minimized.

Copy link
Member

zackmdavis commented Apr 26, 2018

@SimonSapin @nikomatsakis

Can we make this attribute a compilation error when used in places where it would be a no-op? This leaves the option of making it work later without changing the meaning of programs that compile.

I'm confused about how exactly how literally we take our stability guarantee. #[must_use] on trait-impls (and other non-ADT locations) is already a no-op on stable; are we allowed to break programs with such attributes by making it an error?

This seems like it ought to be sheerly hypothetical—why would anyone have already written a program with such no-op attributes? But the fn_must_use feature gate ended up emitting a warning rather an error (which took some extra work) for precisely this reason, which warnings turned out to reveal at least one crate in the wild that was trying to use the #[must_use] attributes even though they were no-oping.

zackmdavis added a commit to zackmdavis/rust that referenced this issue Apr 26, 2018

zackmdavis added a commit to zackmdavis/rust that referenced this issue Apr 26, 2018

stabilize `#[must_use]` for functions and must-use operators
This is in the matter of RFC 1940 and tracking issue rust-lang#43302.
@SimonSapin

This comment has been minimized.

Copy link
Contributor

SimonSapin commented Apr 26, 2018

#[must_use] on trait-impls (and other non-ADT locations) is already a no-op on stable

This is the situation I was hoping to prevent, I didn’t realize it was already the case.

@Havvy

This comment has been minimized.

Copy link
Contributor

Havvy commented Apr 26, 2018

We can make it a hard error on the next edition then.

zackmdavis added a commit to zackmdavis/rust that referenced this issue Apr 28, 2018

stabilize `#[must_use]` for functions and must-use operators
This is in the matter of RFC 1940 and tracking issue rust-lang#43302.

zackmdavis added a commit to zackmdavis/rust that referenced this issue Apr 28, 2018

stabilize `#[must_use]` for functions and must-use operators
This is in the matter of RFC 1940 and tracking issue rust-lang#43302.

zackmdavis added a commit to zackmdavis/rust that referenced this issue Apr 29, 2018

stabilize `#[must_use]` for functions and must-use operators
This is in the matter of RFC 1940 and tracking issue rust-lang#43302.

zackmdavis added a commit to zackmdavis/rust that referenced this issue Apr 29, 2018

stabilize `#[must_use]` for functions and must-use operators
This is in the matter of RFC 1940 and tracking issue rust-lang#43302.

GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue May 3, 2018

stabilize `#[must_use]` for functions and must-use operators
This is in the matter of RFC 1940 and tracking issue rust-lang#43302.
@Havvy

This comment has been minimized.

Copy link
Contributor

Havvy commented May 15, 2018

@aturon The stabilization PR has already gone through. I'm not sure if all the necessary docs are updated yet, although the reference has been.

@Centril

This comment has been minimized.

Copy link
Contributor

Centril commented Oct 31, 2018

@Havvy is there anything left here to do?

@Havvy

This comment has been minimized.

Copy link
Contributor

Havvy commented Nov 4, 2018

I don't know. It's documented in the reference and there's an issue for the API guidelines book. But I don't think it's talked about in TRPL and definitely untouched in Rust By Example, if it should even be in there.

@Centril

This comment has been minimized.

Copy link
Contributor

Centril commented Nov 10, 2018

Closing as completed.

@Centril Centril closed this Nov 10, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.