-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Closed
Closed
Copy link
Labels
C-bugCategory: This is a bug.Category: This is a bug.F-lint_reasons`#![feature(lint_reasons)]``#![feature(lint_reasons)]`T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Description
In its RFC, the #[expect(...)]
lint attribute is said to function identically to #[allow(...)]
. However, when trying out the attribute in the kernel, I found a case where I can see a difference.
The following code does not emit any warning:
fn f() {}
#[allow(dead_code)]
fn g() {
f();
}
However, this does:
fn f() {}
#[expect(dead_code)]
fn g() {
f();
}
In other words, with #[allow(...)]
, f
is understood to be used, because it is called from g
, even if g
is dead code itself. With #[expect(...)]
, f
is understood as not used.
Both 1.71.1 and nightly (32303b2 2023-07-29) behave the same way: https://godbolt.org/z/sMhYh1q11.
Metadata
Metadata
Assignees
Labels
C-bugCategory: This is a bug.Category: This is a bug.F-lint_reasons`#![feature(lint_reasons)]``#![feature(lint_reasons)]`T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.