rust/tests/ui/impl-trait/where-allowed-2.rs

use std::fmt::Debug;

fn in_adt_in_return() -> Vec<impl Debug> { panic!() }
//~^ ERROR type annotations needed

fn main() {}
Fix 'type annotations needed' error with opaque types Related: #66426 This commit adds handling for opaque types during inference variable fallback. Type variables generated from the instantiatino of opaque types now fallback to the opque type itself. Normally, the type variable for an instantiated opaque type is either unified with the concrete type, or with the opaque type itself (e.g when a function returns an opaque type by calling another function). However, it's possible for the type variable to be left completely unconstrained. This can occur in code like this: ```rust pub type Foo = impl Copy; fn produce() -> Option<Foo> { None } ``` Here, we'll instantatiate the `Foo` in `Option<Foo>` to a fresh type variable, but we will never unify it with anything due to the fact that we return a `None`. This results in the error message: `type annotations needed: cannot resolve `_: std::marker::Copy`` pointing at `pub type Foo = impl Copy`. This message is not only confusing, it's incorrect. When an opaque type inference variable is completely unconstrained, we can always fall back to using the opaque type itself. This effectively turns that particular use of the opaque type into a non-defining use, even if it appears in a defining scope. 2019-11-15 01:19:34 +00:00			`use std::fmt::Debug;`

Revert "Auto merge of #93893 - oli-obk:sad_revert, r=oli-obk" This reverts commit 6499c5e7fc173a3f55b7a3bd1e6a50e9edef782d, reversing changes made to 78450d2d602b06d9b94349aaf8cece1a4acaf3a8. 2022-02-14 16:10:22 +00:00			`fn in_adt_in_return() -> Vec<impl Debug> { panic!() }`
Revert diagnostic duplication and accidental stabilization 2022-04-28 13:25:36 +00:00			`//~^ ERROR type annotations needed`
Fix 'type annotations needed' error with opaque types Related: #66426 This commit adds handling for opaque types during inference variable fallback. Type variables generated from the instantiatino of opaque types now fallback to the opque type itself. Normally, the type variable for an instantiated opaque type is either unified with the concrete type, or with the opaque type itself (e.g when a function returns an opaque type by calling another function). However, it's possible for the type variable to be left completely unconstrained. This can occur in code like this: ```rust pub type Foo = impl Copy; fn produce() -> Option<Foo> { None } ``` Here, we'll instantatiate the `Foo` in `Option<Foo>` to a fresh type variable, but we will never unify it with anything due to the fact that we return a `None`. This results in the error message: `type annotations needed: cannot resolve `_: std::marker::Copy`` pointing at `pub type Foo = impl Copy`. This message is not only confusing, it's incorrect. When an opaque type inference variable is completely unconstrained, we can always fall back to using the opaque type itself. This effectively turns that particular use of the opaque type into a non-defining use, even if it appears in a defining scope. 2019-11-15 01:19:34 +00:00
			`fn main() {}`