Design decisions around the `#[expect]` attribute

[xFrednet]

Summary

The #[expect] attribute as proposed in RFC 2383 adds a new attribute that suppresses lint emissions, but issues a warning if the expected lint doesn't trigger anymore. In the proposed RFC it was described as this:

This RFC adds an expect lint attribute that functions identically to allow, but will cause a lint to be emitted when the code it decorates does not raise a lint warning.

A working implementation of the attribute is available in nightly with the lint_reasons feature. See this playground as an example. The goal of this meeting is to resolve the last questions remaining in the tracking issue.

Questions

The questions also contain a collapsed explanation of the current behavior. (This might not work on the mobile view)

1. Should the attribute really be called #[expect] or is the name too generic? src

2. How should the #[expect] attribute interact with other lint attributes, like allow, warn, deny? src

For example, should this code fulfill the expectation or not?

#![feature(lint_reasons)]

#[expect(unused_variables)]
pub fn f() {
    #[warn(unused_variables)]
    let x = 1;
}

Current implementation

Currently, expectations are only fulfilled by lint emissions directly affected by it. The example above would trigger two warnings, one for the unused value x and one for the fulfilled expectation.

3 Should an expectation be fulfilled, by a lint that would otherwise be allowed? src

For example, should this code fulfill the expectation or not?

#![feature(lint_reasons)]
#![allow(unused)]

#[allow(unsafe_code)]
pub fn f() {
    #[expect(unsafe_code)]
    unsafe {
    }
}

Current implementation

The current implementation only checks if a lint is emitted at a node affected by the lint attribute. The example above would therefore fulfill the expectation, just like #[warn] would cause the code to trigger the lint. If this wouldn't be the case, the #[expect] attribute would change behavior based on the outer lint level. This can become confusing if the user defines a lint level via console arguments like this cargo clippy -- -W clippy::pedantic

Background reading

• The tracking issue starting from the stabilization report: Tracking issue for RFC 2383, "Lint Reasons RFC" rust#54503 (comment)
• The RFC: https://rust-lang.github.io/rfcs/2383-lint-reasons.html
• The draft documentation for the current implementation: Document new #[expect] attribute and reasons parameter (RFC 2383) reference#1237

Note

I'd like to attend the meeting as well. It would be awesome if I could be notified when the meeting has been scheduled. I'll also keep an eye on the calender :)

[nikomatsakis]

Hi @xFrednet! Question from the planning meeting this month. Do you think you would have time to author a document for the meeting to guide discussion?

[xFrednet]

Hey @nikomatsakis, it depends on when the meeting is, but I'd be up for it :). Do you have a template or example for the document? I tried to write the issue in a way that already guides the discussion :)

[nikomatsakis]

@xFrednet would March 8th work for you? Our meetings typically held at 13:00 US Eastern time (19:00 CEST). Regarding a template, I can send you some examples-- the key thing would be summarizing enough of the background material to have a self-contained discussion.

i.e., what are some of the proposed answers to those questions, and what are their pros/cons?

bonus points for taking an opinionated position about what you think is best :)

[nikomatsakis]

@xFrednet we're going to take a stab at better doc guidelines, but here are a few docs from past meetings that were productive:

• https://github.com/rust-lang/lang-team/blob/master/design-meeting-minutes/2021-10-13-where-the-where.md
• https://github.com/rust-lang/lang-team/blob/master/design-meeting-minutes/2022-10-05-provenance.md

Key point is to identify clearly the topics to discuss (and, often, what not to discuss) and to give the background needed for that.

Note that the docs include minutes of the actual converations and questions that happened -- best thing is to author the doc in hackmd so we can live edit it during the meeting.

One particular danger is that sometimes docs get too in the weeds with details, where really what is needed from the lang team is more alignment around the high-level goals, or which design features should be prioritized (i.e., the question is not "do we do X or Y" it's "which use case is more important").

[xFrednet]

@nikomatsakis The 8th of March works for me! Thank you for the examples, I'll read through them and take a stab at it :)

[xFrednet]

Hey @nikomatsakis, I've created a document with some background information. The questions which should be discussed as well as the possible solutions. Here is a link:

https://hackmd.io/@xFrednet/rust-lang-team191

I've limited the write permissions for now, but will enable them for the meeting. If you have any comments, I'm happy to address them :)