Decision: semantics of the `#[expect]` attribute

[nikomatsakis]

This issue is spun out from #54503 to serve as the decision issue for a specific question. The question is what the 'mental model' for the expect attribute should be. Two proposed options:

1. The expectation is fulfilled, if a #[warn] attribute in the same location would cause a diagnostic to be emitted. The suppression of this diagnostic fulfills the expectation. (src) (Current implementation in rustc)
2. The expectation is fulfilled if removing the #[expect] attribute would cause the warning to be emitted. (src)

@xFrednet created a list of use cases to help with the discussion of these two models; they found both models work equally well, except for use case 4 which would only be possible with the first model.

[nikomatsakis]

@rustbot labels +T-lang

[nikomatsakis]

@rfcbot fcp merge

I propose that we adopt option 1.

[rfcbot]

Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @tmandry

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[nikomatsakis]

@rustbot labels +F-lint_reasons

[tgross35]

Mind clarifying the title to reference the lint attribute, to not confuse it with .expect()?

[RalfJung]

It also wouldn't hurt clarifying where the two semantics differ. I think they only differ in case the lint is allowed, in which case option 2 would always cause an error on expect since there's nothing being linted? So, option 1 is like having an implicit warn(lint) together with the expect(lint)?

[xFrednet]

• Option 1 acts like a new lint level. The lint level at the outer scope doesn't matter, since it's overwritten by the new "expect" lint level.
• Option 2 acts like a try-and-catch block and the lint level is not affected.

You already mentioned the difference, when it comes to the lint being allowed in the outer scope. The semantics also change, how inner lint levels are handled. Let's take this example:

#![allow(unused)]

#[expect(unused_variables)]
fn foo() {
    #[warn(unused_variables)]
    let bar = "Marker is cool";
}

• Option 1 acts like a new lint level, for the function foo. The #[warn] overwrites the lint level for the let-statement. This causes the unused_variables lint for bar to be emitted and the lint expectation for foo to be unfulfilled
• Option 2 acts like a try-and-catch block. The unused_variables lint emission from bar would be suppressed by the lint expectation of foo. In this case, no warning would be emitted.

This is one of the examples, why I favor option 1. In this example, I would expect to get a warning for bar, since it states #[warn] above it.