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

@oli-obk

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?

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

@Mark-Simulacrum

cc @Mark-Simulacrum @rust-lang/compiler

Beta promotion to stable should happen today...

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.

@oli-obk

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

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

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.

@eddyb

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)

@oli-obk

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.

Seems fine to me!

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

I'm on it

Auto merge of #54741 - oli-obk:impl_trait_hierarchy, r=cramertj

Navigation Menu

Repository navigation

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

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

oli-obk commented on Sep 8, 2018

emilyalbini commented on Sep 10, 2018

eddyb commented on Sep 10, 2018

emilyalbini commented on Sep 10, 2018

oli-obk commented on Sep 10, 2018

eddyb commented on Sep 10, 2018

pnkfelix commented on Sep 13, 2018

pnkfelix commented on Sep 20, 2018

cramertj commented on Sep 20, 2018

pnkfelix commented on Sep 27, 2018

oli-obk commented on Oct 1, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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