Skip to content

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

Closed
#54741
Closed
Regression in #[allow(deprecated)] for impl Trait return type#54045
#54741
Assignees
oli-obk
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.
Milestone
1.29

Description

@cramertj
cramertj
opened on Sep 7, 2018

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

  1. cramertj
    added
    regression-from-stable-to-nightlyPerformance or correctness regression from stable to nightly.
    regression-from-stable-to-betaPerformance or correctness regression from stable to beta.
    A-impl-traitArea: `impl Trait`. Universally / existentially quantified anonymous types with static dispatch.
    on Sep 7, 2018

  2. oli-obk commented on Sep 8, 2018

    @oli-obk
    oli-obk
    on Sep 8, 2018
    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

  3. emilyalbini
    added this to the 1.29 milestone on Sep 10, 2018

  4. emilyalbini commented on Sep 10, 2018

    @emilyalbini
    emilyalbini
    on Sep 10, 2018
    Member

    cc @Mark-Simulacrum @rust-lang/compiler

    Beta promotion to stable should happen today...

  5. emilyalbini
    added
    I-nominated
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    and removed
    regression-from-stable-to-nightlyPerformance or correctness regression from stable to nightly.
    on Sep 10, 2018

  6. eddyb commented on Sep 10, 2018

    @eddyb
    eddyb
    on Sep 10, 2018
    Contributor

    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.

  7. emilyalbini commented on Sep 10, 2018

    @emilyalbini
    emilyalbini
    on Sep 10, 2018
    Member

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

  8. oli-obk commented on Sep 10, 2018

    @oli-obk
    oli-obk
    on Sep 10, 2018
    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

  9. eddyb commented on Sep 10, 2018

    @eddyb
    eddyb
    on Sep 10, 2018
    Contributor

    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.

  10. Mark-Simulacrum
    added
    regression-from-stable-to-stablePerformance or correctness regression from one stable version to another.
    and removed
    regression-from-stable-to-betaPerformance or correctness regression from stable to beta.
    on Sep 12, 2018

  11. pnkfelix commented on Sep 13, 2018

    @pnkfelix
    pnkfelix
    on Sep 13, 2018
    Contributor

    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)

  12. pnkfelix
    added
    P-highHigh priority
    and removed
    I-nominated
    on Sep 13, 2018
  13. pnkfelix
    assigned
    eddyb
    and
    oli-obk
    on Sep 13, 2018
  14. Mark-Simulacrum
    added
    stable-nominatedNominated for backporting to the compiler in the stable channel.
    on Sep 19, 2018

  15. pnkfelix commented on Sep 20, 2018

    @pnkfelix
    pnkfelix
    on Sep 20, 2018
    Contributor

    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.

  16. cramertj commented on Sep 20, 2018

    @cramertj
    cramertj
    on Sep 20, 2018
    MemberAuthor

    Seems fine to me!

  17. Mark-Simulacrum
    removed
    stable-nominatedNominated for backporting to the compiler in the stable channel.
    on Sep 26, 2018

  18. pnkfelix commented on Sep 27, 2018

    @pnkfelix
    pnkfelix
    on Sep 27, 2018
    Contributor

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

  19. oli-obk
    unassigned
    eddyb
    on Oct 1, 2018

  20. oli-obk commented on Oct 1, 2018

    @oli-obk
    oli-obk
    on Oct 1, 2018
    Contributor

    I'm on it

  21. bors
    added a commit that references this issue on Oct 5, 2018

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

    2155f27
  22. bors
    closed this as completedin #54741on Oct 5, 2018
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

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions