Skip to content

#[deprecated] lint doesn't trigger when overriding deprecated method #98990

Open
@m-ou-se

Description

@m-ou-se

This doesn't give any warnings, even though std::error::Error::description is deprecated:

impl std::error::Error for E {
    fn description(&self) -> &str {
        ":)"
    }
}

It seems like this is a deliberate decision:

// Pass `None` to skip deprecation warnings.
self.tcx.check_stability(def_id, None, impl_item_ref.span, None);

Substituting that first None for Some(impl_item_ref.id.hir_id()) makes it work.

Doing so results in the lint triggering in exactly one place in std:

impl Error for Infallible {
fn description(&self) -> &str {
match *self {}
}
}

That's because in all other cases, we have #[allow(deprecated)] there:

impl Error for string::FromUtf16Error {
#[allow(deprecated)]
fn description(&self) -> &str {
"invalid utf-16"
}
}

Which is suprising, as that lint doesn't tigger there, making that #[allow] unnecessary.

It seems as if it used to be necessary in the past, but now no longer is.

Did #[deprecated] trigger on overrides in the past? Was that behavior changed on purpose? Or is it a bug that it doesn't do that anymore?

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-attributesArea: Attributes (`#[…]`, `#![…]`)A-diagnosticsArea: Messages for errors, warnings, and lintsA-lintsArea: Lints (warnings about flaws in source code) such as unused_mut.C-bugCategory: This is a bug.I-lang-radarItems that are on lang's radar and will need eventual work or consideration.L-deprecatedLint: deprecatedT-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