Regression in #[allow(deprecated)] for impl Trait return type

[cramertj]

The following code compiles on stable but fails to compile on beta and nightly with the warning "use of deprecated item Deprecated":

#![deny(warnings)]

#[deprecated]
trait Deprecated {}

#[deprecated]
struct DeprecatedTy;

#[allow(deprecated)]
impl Deprecated for DeprecatedTy {}

#[allow(deprecated)]
fn foo() -> impl Deprecated { DeprecatedTy }

fn main() {
    foo();
}

Error:

error: use of deprecated item 'Deprecated'
  --> src/main.rs:13:18
   |
13 | fn foo() -> impl Deprecated { DeprecatedTy }
   |                  ^^^^^^^^^^
   |
note: lint level defined here
  --> src/main.rs:1:9
   |
1  | #![deny(warnings)]
   |         ^^^^^^^^
   = note: #[deny(deprecated)] implied by #[deny(warnings)]

error: aborting due to previous error

Possibly related to @oli-obk 's refactoring of impl Trait?

[oli-obk]

Possible. Is the deprecation checker running on HIR? because we now have a HIR existential type item, and I don't think we're copying lint attributes from the function over to it

[pietroalbini]

cc @Mark-Simulacrum @rust-lang/compiler

Beta promotion to stable should happen today...

[eddyb]

because we now have a HIR existential type item, and I don't think we're copying lint attributes from the function over to it

Ideally, the HIR would be nested in such a way that the lints implicitly apply to the existential.

[pietroalbini]

Bisected this, the cause of the regression is #51806. cc @oli-obk (author) @cramertj (reviewer)

[oli-obk]

Ideally, the HIR would be nested in such a way that the lints implicitly apply to the existential.

for that we'd either need some form of anonymous modules that fill their items into the outer module, or we'd move the existential type item into the function body (which you were explicitly against), or we'd add a hir::TyKind::Item which contains an actual hir::Item

[eddyb]

or we'd add a hir::TyKind::Item which contains an actual hir::Item

This is the closest to a real fix IMO, the path trick is cool but problematic.

[pnkfelix]

visited at compiler team meeting. P-high. Assigning to both @eddyb and @oli-obk

@oli-obk : if you're not available , just remove your assignment (but realize you are ceding authority! ha ha ha)

[pnkfelix]

Discussed at T-compiler meeting

Some notes:

• There exists a workaround; namely, one can tag a containing item with the #[allow(..)], as demonstrated here on play.
• Since there exists a workaround, and the bug has at this point leaked out to stable, it seems unlikely that we would attempt a full backport all the way to stable.
• And therefore, we are willing to wait for @oli-obk to return in order to work together with @eddyb to identify the best fix for this bug.
• So, we're keeping this at P-high, but we're not striving to make a PR that would be backport-able to stable nor to beta.)
• Having said that, I'm leaving the stable-nominated tag on the bug so that @oli-obk and/or @cramertj get a chance to chime in before we remove it.

[cramertj]

Seems fine to me!

[pnkfelix]

visited for triage. No change in status; plan of record remains as recorded in my previous comment.

[oli-obk]

I'm on it