Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
m-ou-se opened this issue Jul 6, 2022 · 3 comments · May be fixed by #98991
Open

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

m-ou-se opened this issue Jul 6, 2022 · 3 comments · May be fixed by #98991
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) A-diagnostics Area: Messages for errors, warnings, and lints C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@m-ou-se
Copy link
Member

m-ou-se commented Jul 6, 2022

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?

@m-ou-se m-ou-se added A-attributes Area: Attributes (`#[…]`, `#![…]`) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. C-bug Category: This is a bug. A-diagnostics Area: Messages for errors, warnings, and lints labels Jul 6, 2022
@m-ou-se m-ou-se linked a pull request Jul 6, 2022 that will close this issue
@m-ou-se
Copy link
Member Author

m-ou-se commented Jul 6, 2022

cc @rust-lang/libs-api, should the #[deprecated] lint trigger here or not?

@eddyb
Copy link
Member

eddyb commented Jul 7, 2022

(reposting #98991 (comment) here as well)

I'm not sure what happened here, but the lack of tests for this is worrying (and may explain how this happened, if it was accidental).

EDIT: much more comprehensive analysis posted in #98991 (comment).

@thomaseizinger
Copy link
Contributor

I just ran into this. I'd like to guide my users away from implementing one trait function to new ones in a backwards-compatible way. My thinking was:

  • Add new trait functions with default implementations that call the old one.
  • Deprecate the old function.

I was expecting to have users (the trait provides a plugin-like functionality, so has many external users outside the crate) to see a deprecation warning that they should no longer implement this function but a new one instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) A-diagnostics Area: Messages for errors, warnings, and lints C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants