Implementation of the expect attribute (RFC 2383)

[xFrednet]

This is an implementation of the expect attribute as described in RFC-2383. The attribute allows the suppression of lint message by expecting them. Unfulfilled lint expectations (meaning no expected lint was caught) will emit the unfulfilled_lint_expectations lint at the expect attribute.

Example

input

// required feature flag
#![feature(lint_reasons)]

#[expect(unused_mut)] // Will warn about an unfulfilled expectation
#[expect(unused_variables)] // Will be fulfilled by x
fn main() {
    let x = 0;
}

output

warning: this lint expectation is unfulfilled
  --> $DIR/trigger_lint.rs:3:1
   |
LL | #[expect(unused_mut)] // Will warn about an unfulfilled expectation
   |          ^^^^^^^^^^
   |
   = note: `#[warn(unfulfilled_lint_expectations)]` on by default

Implementation

This implementation introduces Expect as a new lint level for diagnostics, which have been expected. All lint expectations marked via the expect attribute are collected in the LintLevelsBuilder and assigned an ID that is stored in the new lint level. The LintLevelsBuilder stores all found expectations and the data needed to emit the unfulfilled_lint_expectations in the LintLevelsMap which is the result of the lint_levels() query.

The rustc_errors::HandlerInner is the central error handler in rustc and handles the emission of all diagnostics. Lint message with the level Expect are suppressed during this emission, while the expectation ID is stored in a set which marks them as fulfilled. The last step is then so simply check if all expectations collected by the LintLevelsBuilder in the LintLevelsMap have been marked as fulfilled in the rustc_errors::HandlerInner. Otherwise, a new lint message will be emitted.

The implementation of the LintExpectationId required some special handling to make it stable between sessions. Lints can be emitted during EarlyLintPasses. At this stage, it's not possible to create a stable identifier. The level instead stores an unstable identifier, which is later converted to a stable LintExpectationId.

Followup TO-DOs

Moved to: #85549

Open questions

I also have a few open questions where I would like to get feedback on:

1. The RFC discussion included a suggestion to change the expect attribute to something else. (Initiated by @Ixrec here, suggestion from @scottmcm to use #[should_lint(...)] here). No real conclusion was drawn on that point from my understanding. Is this still open for discussion, or was this discarded with the merge of the RFC?
2. How should the expect attribute deal with the new force-warn lint level?

---

This approach was inspired by a discussion with @LeSeulArtichaut.

RFC tracking issue: #54503

Mentoring/Implementation issue: #85549

[LeSeulArtichaut]

I don't think I can help much with this. You might want to add a test for macros however.

[xFrednet]

That's a very good pointer, thank you for taking a look 🙃

[xFrednet]

Hello, I believe that this PR is ready for review. There is definitely one To-Do that has to be addressed before the merge when it comes to incremental compilation and the stability of the LintExpectationId. However, I would first like to get some feedback if the structure implementation is good before diving further into this.

@flip1995 You offered in the last PR to aid with the review. I would appreciate it if you could take a look at this one and maybe give some feedback 🙃.

r? @wesleywiser Would you be willing to take over the main review of this? 🙃

[flip1995]

Something that came to my mind this morning under the shower: What if you expect an EarlyLintPass and a LateLintPass lint at the same item. So:

#[expect(some_early_lints)]
#[expect(some_late_lints)]
fn foo() {
    // code triggering all specified lints
}

I think this isn't a problem after #87337 gets merged, but I would add a test for it anyway.

[xFrednet]

What if you expect an EarlyLintPass and a LateLintPass lint at the same item.

That's a good thought. The expectations are currently checked at the end of the last lint pass, meaning that it should still work as expected. Adding a test for it is still a very good idea. I'll look up some lints for a test like that.

---

What are your thoughts on an example where an item has multiple expect attributes with the same lint? For instance

#[expect(unused_variables)] // 1
#[expect(unused_variables)] // 2
fn main() {
    let x = 0;
}

A test with normal lint levels shows that they are processed in order top-down (example playground). This means that the current implementation would mark the second expectation as fulfilled, and lint about the first one. Does this seem reasonable? 🙃

[flip1995]

This means that the current implementation would mark the second expectation as fulfilled, and lint about the first one. Does this seem reasonable? 🙃

Intuitively I would expect no warning in this case, if adding 2 identical allow attributes don't produce a warning either. IMO the current behavior is fine for now as long as it is unstable, but before stabilizing it this is an open question that should be addressed.

[xFrednet]

The usage of FxHashMap made a few problems as the expectation check order was not constant. I've rebased and added a new commit to use a Vec instead. The other commits stayed the same. 🙃 The usage of the HashMap was actually a relic of the past. This is a nice improvement :)

@bors try

[bors]

⌛ Trying commit 5275d02 with merge 5d83a73fa38efb9763fdd19f1d6ffdb90cc99de7...

[bors]

☀️ Try build successful - checks-actions
Build commit: 5d83a73fa38efb9763fdd19f1d6ffdb90cc99de7 (5d83a73fa38efb9763fdd19f1d6ffdb90cc99de7)

[wesleywiser]

@bors r+

[bors]

📌 Commit 5275d02 has been approved by wesleywiser

[bors]

⌛ Testing commit 5275d02 with merge 10913c0...

[bors]

☀️ Test successful - checks-actions
Approved by: wesleywiser
Pushing 10913c0 to master...

[rust-timer]

Finished benchmarking commit (10913c0): comparison url.

Summary: This benchmark run did not return any relevant results. 9 results were found to be statistically significant but too small to be relevant.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression