Closed
Description
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
oli-obk commentedon Sep 8, 2018
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 commentedon Sep 10, 2018
cc @Mark-Simulacrum @rust-lang/compiler
Beta promotion to stable should happen today...
eddyb commentedon Sep 10, 2018
Ideally, the HIR would be nested in such a way that the lints implicitly apply to the existential.
pietroalbini commentedon Sep 10, 2018
Bisected this, the cause of the regression is #51806. cc @oli-obk (author) @cramertj (reviewer)
oli-obk commentedon Sep 10, 2018
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 actualhir::Item
eddyb commentedon Sep 10, 2018
This is the closest to a real fix IMO, the path trick is cool but problematic.
16 remaining items