Skip to content

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

Closed
@cramertj

Description

@cramertj
Member

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?

Activity

added
A-impl-traitArea: `impl Trait`. Universally / existentially quantified anonymous types with static dispatch.
on Sep 7, 2018
oli-obk

oli-obk commented on Sep 8, 2018

@oli-obk
Contributor

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

added this to the 1.29 milestone on Sep 10, 2018
pietroalbini

pietroalbini commented on Sep 10, 2018

@pietroalbini
Member

cc @Mark-Simulacrum @rust-lang/compiler

Beta promotion to stable should happen today...

added
T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
and removed on Sep 10, 2018
eddyb

eddyb commented on Sep 10, 2018

@eddyb
Member

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

pietroalbini commented on Sep 10, 2018

@pietroalbini
Member

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

oli-obk

oli-obk commented on Sep 10, 2018

@oli-obk
Contributor

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

eddyb commented on Sep 10, 2018

@eddyb
Member

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.

16 remaining items

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

Metadata

Metadata

Assignees

Labels

A-impl-traitArea: `impl Trait`. Universally / existentially quantified anonymous types with static dispatch.P-highHigh priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-stablePerformance or correctness regression from one stable version to another.

Type

No type

Projects

No projects

Relationships

None yet

    Development

    Participants

    @eddyb@pnkfelix@oli-obk@pietroalbini@Mark-Simulacrum

    Issue actions

      Regression in #[allow(deprecated)] for `impl Trait` return type · Issue #54045 · rust-lang/rust