Add unstable #[may_ignore] attribute to cancel #[must_use]

[m-ou-se]

This adds an unstable #[may_ignore] attribute, that can cancel the effect of a #[must_use] attribute. This is useful when the result of a function can be safely ignored, but it returns a #[must_use] type such as a Result.

---

Edit: Example usage of this: #78822

[rust-highfive]

r? @lcnr

(rust-highfive has picked a reviewer for you, use r? to override)

[m-ou-se]

// TODO: This still needs a real tracking issue.

[egilburg]

Soon to be followed by #[cannot_ignore] to cancel out the may_ignore attribute, which cancels out the must_use attribute? 😆 Is there a better approach than arms race between the function author and user? What is the actual motivation for must_use to be a semantic requirement rather than a suggestion?

[m-ou-se]

This is just to be able to make the must_use warning a bit smarter. Rust warns about all ignored Results by default, but in some cases it's fine to ignore. This allows turning the warning off for specific functions.

Would you have any use case for #[cannot_ignore]?

[egilburg]

Not really, just a humorous reply. Perhaps it's actually valuable, in which case go ahead. It just reminds me of the cautionary tale of the "arms race" (anti) patterns in other languages, where code exist to suppress other code, instead of working through why the original code was set up that way to begin with. E.g. !important tag in CSS.

[Mark-Simulacrum]

@m-ou-se One thing I'd like to clarify -- does this have transitive effects?

#[may_ignore]
fn bar() -> Result<usize, usize> { todo!() }

// is this must_use or may_ignore?
fn foo() -> Result<usize, usize> { bar() }

I am not sure which behavior is preferable myself, I think either could be reasonable..

[m-ou-se]

@Mark-Simulacrum Same as the other way around, so not transitive:

#[must_use]
fn bar() -> usize { todo!() }

fn foo() -> usize { bar() } // not must_use

#[may_ignore]
fn bar() -> Result<usize, usize> { todo!() }

fn foo() -> Result<usize, usize> { bar() } // not may_ignore (so, must_use)

[lcnr]

can you forbid may_ignore when applied to invalid items similar to what #79073 is doing?

We also aren't checking this for must_use :/
Would be nice to fix this in a different PR as that probably requires crater.

Not sure if someone needs to sign this off before merging, cc @rust-lang/lang

[the8472]

Soon to be followed by #[cannot_ignore] to cancel out the may_ignore attribute, which cancels out the must_use attribute? 😆

Don't forget warnings about useless may_ignores applied to values that aren't must_use!

[lukaslueg]

Soon to be followed by #[cannot_ignore] to cancel out the may_ignore attribute, which cancels out the must_use attribute? 😆

Don't forget warnings about useless may_ignores applied to values that aren't must_use!

I always compile with #[allow(probably_deny_may_ignore_allow_must_use_maybe)])

[scottmcm]

Some rationale here that came up in the triage meeting which I wanted to write down in the PR: This can't be solved by looking for uninhabited error types (like it could for u64::try_from(0_u32)) because this is desired mostly for cases where the method must (either because of a trait or backward compatibility) use a common error type that's always inhabited.

[joshtriplett]

Bikeshedding about names aside, this seems reasonable to me.

There was some discussion in the meeting about whether it'd be feasible to apply this attribute to a specific impl of a trait, such that if you're in a non-generic context and using that specific impl, the compiler could avoid emitting the warning. That seems reasonable as well, assuming that it's implementable in the compiler.

[bors]

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

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

[nikomatsakis]

Update from the lang meeting today:

We would like to see some examples of where this ought to be used. One of them that we came up with was when you have a trait that returns result, but you know the impl only returns Ok, but the PR needs an update to support that.

Are there other examples, @m-ou-se?

[nikomatsakis]

Some concrete examples of this pattern:

• Implementations of std::io::Write for things like String or what have you.

[Dylan-DPC-zz]

@m-ou-se any updates?

[Dylan-DPC-zz]

closing this due to inactivity.