rust/src/test/ui/impl-trait/where-allowed-2.rs

//! Ideally, these tests would go in `where-allowed.rs`, but we bail out
//! too early to display them.
use std::fmt::Debug;

// Disallowed
fn in_adt_in_return() -> Vec<impl Debug> { panic!() } //~ ERROR cannot resolve opaque type

fn main() {}
Revert "Auto merge of #92007 - oli-obk:lazy_tait2, r=nikomatsakis" This reverts commit e7cc3bddbe0d0e374d05e7003e662bba1742dbae, reversing changes made to 734368a200904ef9c21db86c595dc04263c87be0. 2022-02-11 07:18:06 +00:00			//! Ideally, these tests would go in `where-allowed.rs`, but we bail out
			`//! too early to display them.`
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-14 20:19:34 -05:00			`use std::fmt::Debug;`

Revert "Auto merge of #92007 - oli-obk:lazy_tait2, r=nikomatsakis" This reverts commit e7cc3bddbe0d0e374d05e7003e662bba1742dbae, reversing changes made to 734368a200904ef9c21db86c595dc04263c87be0. 2022-02-11 07:18:06 +00:00			`// Disallowed`
			`fn in_adt_in_return() -> Vec<impl Debug> { panic!() } //~ ERROR cannot resolve opaque type`
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-14 20:19:34 -05:00
			`fn main() {}`