Fix 'type annotations needed' error with opaque types #66431

Aaron1011 · 2019-11-15T02:30:21Z

Related: #66426

This commit adds handling for opaque types during inference variable
fallback. Type variables generated from the instantiation of opaque
types now fallback to the opaque 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:

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.

rust-highfive · 2019-11-15T02:30:25Z

r? @davidtwco

(rust_highfive has picked a reviewer for you, use r? to override)

src/test/ui/type-alias-impl-trait/fallback.rs

Centril · 2019-11-15T10:45:32Z

r? @varkor
cc @nikomatsakis

bors · 2019-11-15T17:00:12Z

☔ The latest upstream changes (presumably #66449) made this pull request unmergeable. Please resolve the merge conflicts.

src/librustc_typeck/check/mod.rs

src/test/ui/impl-trait/where-allowed-2.stderr

estebank · 2019-11-15T04:08:26Z

src/test/ui/type-alias-impl-trait/fallback.rs

+}
+
+fn _produce() -> Wrapper<Foo> {
+    Wrapper::Second


I'm not sure this entirely correct. What is the final type of Foo?

Final type is bool as determined by constrained_foo.

Centril

nits

src/librustc_typeck/check/mod.rs

src/librustc/infer/opaque_types/mod.rs

src/librustc_typeck/check/mod.rs

Aaron1011 · 2019-11-15T23:18:43Z

@Centril @estebank: I've addressed your comments.

varkor

I'm happy with the implementation once the nits have been addressed and rebased into the main commits.

src/librustc_typeck/check/mod.rs

src/test/ui/impl-trait/where-allowed-2.stderr

Related: rust-lang#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.

Aaron1011 · 2019-11-18T19:02:22Z

@varkor: Squashed

varkor · 2019-11-18T19:12:40Z

@bors r+

bors · 2019-11-18T19:12:41Z

📌 Commit a11abe0 has been approved by varkor

…varkor Fix 'type annotations needed' error with opaque types Related: rust-lang#66426 This commit adds handling for opaque types during inference variable fallback. Type variables generated from the instantiation of opaque types now fallback to the opaque 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.

@ghost

Rollup of 13 pull requests Successful merges: - #66090 (Misc CI improvements) - #66239 (Suggest calling async closure when needed) - #66430 ([doc] Fix the source code highlighting on source comments) - #66431 (Fix 'type annotations needed' error with opaque types) - #66461 (Add explanation message for E0641) - #66468 (Cleanup Miri SIMD intrinsics) - #66478 (rustc_plugin: Remove the compatibility shim) - #66493 (Add JohnTitor to rustc-guide toolstate notification list) - #66511 (std::error::Chain: remove Copy) - #66512 (Add unix::process::CommandExt::arg0) - #66520 (Disable gdb pretty printer global section on wasm targets) - #66529 (resolve: Give derive helpers highest priority during resolution) - #66536 (Move the definition of `QueryResult` into `plumbing.rs`.) Failed merges: r? @ghost

…varkor Fix 'type annotations needed' error with opaque types Related: rust-lang#66426 This commit adds handling for opaque types during inference variable fallback. Type variables generated from the instantiation of opaque types now fallback to the opaque 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.

@ghost

Rollup of 11 pull requests Successful merges: - #66090 (Misc CI improvements) - #66155 (Add long error explanation for E0594) - #66239 (Suggest calling async closure when needed) - #66430 ([doc] Fix the source code highlighting on source comments) - #66431 (Fix 'type annotations needed' error with opaque types) - #66461 (Add explanation message for E0641) - #66493 (Add JohnTitor to rustc-guide toolstate notification list) - #66511 (std::error::Chain: remove Copy) - #66529 (resolve: Give derive helpers highest priority during resolution) - #66536 (Move the definition of `QueryResult` into `plumbing.rs`.) - #66538 (Remove compiler_builtins_lib feature from libstd) Failed merges: r? @ghost

bors · 2019-11-19T15:26:23Z

☔ The latest upstream changes (presumably #66545) made this pull request unmergeable. Please resolve the merge conflicts.

rust-highfive assigned davidtwco Nov 15, 2019

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 15, 2019

Aaron1011 mentioned this pull request Nov 15, 2019

Impossible to return unboxed closure from some functions. #66426

Closed

Centril reviewed Nov 15, 2019

View reviewed changes

src/test/ui/type-alias-impl-trait/fallback.rs Show resolved Hide resolved

Centril added the F-type_alias_impl_trait `#[feature(type_alias_impl_trait)]` label Nov 15, 2019

rust-highfive assigned varkor and unassigned davidtwco Nov 15, 2019

estebank reviewed Nov 15, 2019

View reviewed changes

Centril reviewed Nov 15, 2019

View reviewed changes

Aaron1011 force-pushed the fix/opaque-type-infer branch from 507e3c0 to 8daaa68 Compare November 15, 2019 21:51

varkor reviewed Nov 18, 2019

View reviewed changes

Aaron1011 added 4 commits November 18, 2019 14:01

Add explanation of unconstrained opaque type

61c75bd

Replace bool with new FallbackMode enum

f87177b

Update test output

a11abe0

Aaron1011 force-pushed the fix/opaque-type-infer branch from 42ed8b8 to a11abe0 Compare November 18, 2019 19:02

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 18, 2019

JohnTitor mentioned this pull request Nov 19, 2019

Rollup of 13 pull requests #66542

Closed

Centril mentioned this pull request Nov 19, 2019

Rollup of 11 pull requests #66545

Merged

bors merged commit a11abe0 into rust-lang:master Nov 19, 2019

Aaron1011 deleted the fix/opaque-type-infer branch November 19, 2019 15:24

bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Nov 19, 2019

Aaron1011 mentioned this pull request Nov 19, 2019

Don't leave 'unmergeable' messages on merged PRs rust-lang/homu#78

Open

voidc mentioned this pull request Jul 7, 2021

min_type_alias_impl_trait: poor diagnostics when TAIT is unconstrained #86733

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix 'type annotations needed' error with opaque types #66431

Fix 'type annotations needed' error with opaque types #66431

Aaron1011 commented Nov 15, 2019 •

edited by Centril

Loading

rust-highfive commented Nov 15, 2019

Centril commented Nov 15, 2019

bors commented Nov 15, 2019

estebank Nov 15, 2019

Centril Nov 15, 2019

Centril left a comment

Aaron1011 commented Nov 15, 2019

varkor left a comment

Aaron1011 commented Nov 18, 2019

varkor commented Nov 18, 2019

bors commented Nov 18, 2019

bors commented Nov 19, 2019

Fix 'type annotations needed' error with opaque types #66431

Fix 'type annotations needed' error with opaque types #66431

Conversation

Aaron1011 commented Nov 15, 2019 • edited by Centril Loading

rust-highfive commented Nov 15, 2019

Centril commented Nov 15, 2019

bors commented Nov 15, 2019

estebank Nov 15, 2019

Choose a reason for hiding this comment

Centril Nov 15, 2019

Choose a reason for hiding this comment

Centril left a comment

Choose a reason for hiding this comment

Aaron1011 commented Nov 15, 2019

varkor left a comment

Choose a reason for hiding this comment

Aaron1011 commented Nov 18, 2019

varkor commented Nov 18, 2019

bors commented Nov 18, 2019

bors commented Nov 19, 2019

Aaron1011 commented Nov 15, 2019 •

edited by Centril

Loading