Skip to content

#[expect(dead_code)] does not behave identically to #[allow(dead_code)] #114557

Closed

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.

Cc'ing @xFrednet and @fmease who may be interested in this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

Labels

C-bugCategory: This is a bug.F-lint_reasons`#![feature(lint_reasons)]`T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions