Skip to content

Cannot infer type even if specified. #42424

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

Open
jD91mZM2 opened this issue Jun 4, 2017 · 11 comments
Open

Cannot infer type even if specified. #42424

jD91mZM2 opened this issue Jun 4, 2017 · 11 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-inference Area: Type inference A-suggestion-diagnostics Area: Suggestions generated by the compiler applied by `cargo fix` C-enhancement Category: An issue proposing an enhancement or a PR with one. F-try_blocks `#![feature(try_blocks)]` requires-nightly This issue requires a nightly compiler in some way. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@jD91mZM2
Copy link
Contributor

jD91mZM2 commented Jun 4, 2017

So, I got the type annotations needed error. I tried everything. It refuses to work.

		let tmp: Result<NamedTempFile, ()> = NamedTempFile::new().map_err::<(), _>(|_: std::io::Error| ());
		let mut tmp: NamedTempFile = tmp?;

Error

image

(please don't tell me the code is stupid. I have a valid reason to ignore the error)

If this is my fault, and not an issue with Rust, apologies for spamming you with yet another false issue :(
I feel horrible

@jD91mZM2 jD91mZM2 changed the title Cannot interfeared type even if specified. Cannot interfered type even if specified. Jun 4, 2017
@jD91mZM2 jD91mZM2 changed the title Cannot interfered type even if specified. Cannot interfere type even if specified. Jun 4, 2017
@retep998
Copy link
Member

retep998 commented Jun 4, 2017

Could you provide the entire function for context? ? especially depends on the signature of the function it is in.

@jD91mZM2
Copy link
Contributor Author

jD91mZM2 commented Jun 4, 2017

It's in a do catch without any variable assigning (do catch { ... };).

@Mark-Simulacrum
Copy link
Member

Well, the whole function would also make it a little easier to see context in general -- right now, I can't even attempt to run this, which makes it hard to debug.

@jD91mZM2
Copy link
Contributor Author

jD91mZM2 commented Jun 4, 2017

Oh, I'm sorry. Here it is. Ignore the unfinishedness of it. That's because it is. Unfinished. I'm trying to get rid of the play function and instead use a catch block.

@Mark-Simulacrum
Copy link
Member

Is there a chance you could produce an example that doesn't rely on external crates? That makes debugging easier. If that's not possible, no worries.

@Mark-Simulacrum Mark-Simulacrum added A-inference Area: Type inference A-catch labels Jun 23, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jul 27, 2017
@Mark-Simulacrum Mark-Simulacrum changed the title Cannot interfere type even if specified. Cannot infer type even if specified. Jul 27, 2017
@dsprenkels
Copy link
Contributor

dsprenkels commented Aug 5, 2017

The following code triggers the same error on rustc 1.21.0-nightly (d692a91fa 2017-08-04):

#![feature(catch_expr)]

pub struct X;

pub fn new_x() -> Result<X, ()> {
    return Ok(X);
}

fn main() {
    do catch {
        let x: X = new_x()?;
        Ok(())
    };
}

(https://play.rust-lang.org/?gist=ffd0e7e68eb97486bf742bd63cc9cb2f&version=nightly)

@jD91mZM2
Copy link
Contributor Author

jD91mZM2 commented Aug 5, 2017

@Mark-Simulacrum I have no idea why I didn't reply - probably forgot about it. I'm so sorry for being rude.

@dsprenkels Thanks!!

Seems like the problem is just in general returning a () error from do catch?

@dsprenkels
Copy link
Contributor

dsprenkels commented Aug 5, 2017

I'm not really sure. The following code fails:

#![feature(catch_expr)]

fn main() {
    do catch {
        let x: () = Ok(())?;
        Ok(())
    };
}

But changing the return type does not seem to help. The following code also fails:

#![feature(catch_expr)]

fn main() {
    do catch {
        let x: () = Ok(())?;
        Ok(42)
    };
}

Note: the type of x also does not seem to matter.

@kennytm
Copy link
Member

kennytm commented Aug 5, 2017

To fix it you need to give a type to the catch expression, not the let declaration. The problem is that it cannot infer the error type due to use of From in ?.

#![feature(catch_expr)]

pub struct X;

pub fn new_x() -> Result<X, ()> {
    return Ok(X);
}

fn main() {
    let _: Result<_, ()> = do catch {   // <---------
        let x: X = new_x()?;
        Ok(())
    };
}

The library should be able to instruct the inference engine to consider impl<T> From<T> for T as canonical impl, and choose that in case of ambiguity.

(And yes, the diagnostic is also an issue.)

@estebank
Copy link
Contributor

estebank commented Aug 28, 2019

The updated code will only work on 2018 edition:

#![feature(try_blocks)]

pub struct X;

pub fn new_x() -> Result<X, ()> {
    return Ok(X);
}

fn main() {
    try {
        let x: X = new_x()?;
        Ok(())
    };
}

and result in

error[E0284]: type annotations required: cannot resolve `<_ as std::ops::Try>::Ok == _`
  --> src/main.rs:11:20
   |
11 |         let x: X = new_x()?;
   |                    ^^^^^^^^

It should be possible to turn it into the following relatively easily

error[E0284]: type annotations required: cannot resolve `<_ as std::ops::Try>::Ok == _`
  --> src/main.rs:11:20
   |
11 |         let x: X = new_x()?;
   |                    ^^^^^^^^
help: give a type to the `try` block without `_` type argument placeholders:
   |
10 |     let _: Result<_, _> = try {
   |     ^^^^^^^^^^^^^^^^^^^^^

@estebank estebank added A-diagnostics Area: Messages for errors, warnings, and lints A-suggestion-diagnostics Area: Suggestions generated by the compiler applied by `cargo fix` F-try_blocks `#![feature(try_blocks)]` requires-nightly This issue requires a nightly compiler in some way. labels Aug 28, 2019
@estebank estebank added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Oct 15, 2019
@estebank
Copy link
Contributor

Current output:

error[E0282]: type annotations needed
  --> src/main.rs:12:9
   |
12 |         Ok(())
   |         ^^ cannot infer type of the type parameter `E` declared on the enum `Result`
   |
help: consider specifying the generic arguments
   |
12 |         Ok::<(), E>(())
   |           +++++++++

After specifying the error type in the tail expression, we get another inference error on the ?:

error[E0283]: type annotations needed
  --> src/main.rs:11:27
   |
11 |         let x: X = new_x()?;
   |                           ^ cannot infer type
   |
   = note: multiple `impl`s satisfying `_: FromResidual<Result<Infallible, ()>>` found in the `core` crate:
           - impl<T, E, F> FromResidual<Result<Infallible, E>> for Poll<Option<Result<T, F>>>
             where F: From<E>;
           - impl<T, E, F> FromResidual<Result<Infallible, E>> for Poll<Result<T, F>>
             where F: From<E>;
           - impl<T, E, F> FromResidual<Result<Infallible, E>> for Result<T, F>
             where F: From<E>;

@fmease fmease removed the A-catch label Apr 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-inference Area: Type inference A-suggestion-diagnostics Area: Suggestions generated by the compiler applied by `cargo fix` C-enhancement Category: An issue proposing an enhancement or a PR with one. F-try_blocks `#![feature(try_blocks)]` requires-nightly This issue requires a nightly compiler in some way. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

7 participants