-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Impossible to return unboxed closure from some functions. #66426
Comments
Minimized: #![feature(type_alias_impl_trait)]
#![feature(trait_alias)]
type Foo = impl Copy;
enum Wrapper<T> {
First(T),
Second
}
fn produce() -> Wrapper<Foo> {
Wrapper::Second
} This appears to be caused by the fact that we create a new inference variable for As a side note, we should probably be cheking for type errors when we collect opaque type uses, so that we don't print useless errors like:
|
@Aaron1011 thanks for tracking it down. Tbh, I don't see why your code is a minimized version of mine – I don't return from any function variant without the impl trait. This is just a note – I don't know the internals of rustc so I can miss a lot of info here :) |
I've opened #66431. It addresses the first 'layer' of errors, but there appear to more (thankfully, better) errors that appear after this one is no longer emitted. |
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.
…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.
…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.
This now compiles on the latest nightly. |
Actually, this does not compile - I didn't use the modified |
Errors on current master:
|
|
The minimized example (playground: #![feature(min_type_alias_impl_trait)]
type Foo = impl Copy;
enum Wrapper<T> {
First(T),
Second
}
fn produce() -> Wrapper<Foo> {
Wrapper::Second
} gives what appears to me to be the correct error:
but the diagnostics are not very good. |
In particular, the value of #![feature(min_type_alias_impl_trait)]
type Foo = impl Copy;
enum Wrapper<T> {
First(T),
Second
}
fn produce() -> Wrapper<Foo> {
Wrapper::First(22)
} then it works. |
The diagnostic for #![feature(type_alias_impl_trait)]
type Foo = impl Copy;
enum Wrapper<T> {
First(T),
Second
}
fn produce() -> Wrapper<Foo> {
Wrapper::Second
} is now
|
I don't believe there is anything left to do here. Please open a new issue if there are issues beyond the failure to infer the type |
Hi! I'm trying to write a lens library for Rust (see this for reference about lenses: https://github.com/ekmett/lens/wiki). I'm trying to write it in an zero-overhead style, so all lens-usages could be optimized away during compilation stage, thus, I'm trying to create unboxed closures and glue them together. However, a very strange error occurs here. Consider the following code:
It compiles fine. However, if you try to return
wrapper
from the_Some
function, the code will not compile and the errrors we get are not very explanatory either. With this code instead:We get:
The text was updated successfully, but these errors were encountered: