Skip to content
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

Resolve failures cause too many typechecking failures #31997

Closed
alexcrichton opened this issue Mar 1, 2016 · 11 comments
Closed

Resolve failures cause too many typechecking failures #31997

alexcrichton opened this issue Mar 1, 2016 · 11 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints

Comments

@alexcrichton
Copy link
Member

I noticed that on #31618 there was a resolve failure from this line, specifically:

../src/libstd/sys/unix/pipe.rs:94:13: 94:25 error: unresolved name `libc::select` [E0425]
../src/libstd/sys/unix/pipe.rs:94             libc::select(max + 1, &mut read, 0 as *mut _, 0 as *mut _,
                                              ^~~~~~~~~~~~
../src/libstd/sys/unix/pipe.rs:90:9: 96:13 note: in this expansion of try! (defined in <core macros>)
../src/libstd/sys/unix/pipe.rs:94:13: 94:25 help: run `rustc --explain E0425` to see a detailed explanation
../src/libstd/sys/unix/pipe.rs:90:14: 90:19 error: the trait `core::num::One` is not implemented for the type `()` [E0277]
../src/libstd/sys/unix/pipe.rs:90         try!(cvt_r(|| unsafe {
                                               ^~~~~
../src/libstd/sys/unix/pipe.rs:90:9: 96:13 note: in this expansion of try! (defined in <core macros>)
../src/libstd/sys/unix/pipe.rs:90:14: 90:19 help: run `rustc --explain E0277` to see a detailed explanation
../src/libstd/sys/unix/pipe.rs:90:14: 90:19 note: required by `sys::cvt_r`
../src/libstd/sys/unix/pipe.rs:90:14: 90:19 error: the trait `core::ops::Neg` is not implemented for the type `()` [E0277]
../src/libstd/sys/unix/pipe.rs:90         try!(cvt_r(|| unsafe {
                                               ^~~~~
../src/libstd/sys/unix/pipe.rs:90:9: 96:13 note: in this expansion of try! (defined in <core macros>)
../src/libstd/sys/unix/pipe.rs:90:14: 90:19 help: run `rustc --explain E0277` to see a detailed explanation
../src/libstd/sys/unix/pipe.rs:90:14: 90:19 note: required by `sys::cvt_r`
../src/libstd/sys/unix/pipe.rs:94:46: 94:57 error: casting `usize` as `*mut _` is invalid
../src/libstd/sys/unix/pipe.rs:94             libc::select(max + 1, &mut read, 0 as *mut _, 0 as *mut _,
                                                                               ^~~~~~~~~~~
../src/libstd/sys/unix/pipe.rs:90:9: 96:13 note: in this expansion of try! (defined in <core macros>)
../src/libstd/sys/unix/pipe.rs:94:59: 94:70 error: casting `usize` as `*mut _` is invalid
../src/libstd/sys/unix/pipe.rs:94             libc::select(max + 1, &mut read, 0 as *mut _, 0 as *mut _,
                                                                                            ^~~~~~~~~~~
../src/libstd/sys/unix/pipe.rs:90:9: 96:13 note: in this expansion of try! (defined in <core macros>)
../src/libstd/sys/unix/pipe.rs:95:26: 95:37 error: casting `usize` as `*mut _` is invalid
../src/libstd/sys/unix/pipe.rs:95                          0 as *mut _)
                                                           ^~~~~~~~~~~
../src/libstd/sys/unix/pipe.rs:90:9: 96:13 note: in this expansion of try! (defined in <core macros>)

The only real error here is that libc::select doesn't exist. All other errors are spawned off of this. This unfortunately makes it pretty hard to hunt through errors and figure out which ones need to get fixed, and at this point I'm just training myself to only look at the first error as all others are likely not too useful.

I attempted to minimize this as well:

mod foo {}

fn bar<T: Clone>() {}

fn main() {
    bar(foo::bar());
}

But this yielded a different error message:

foo.rs:6:9: 6:17 error: unresolved name `foo::bar` [E0425]
foo.rs:6     bar(foo::bar());
                 ^~~~~~~~
foo.rs:6:9: 6:17 help: run `rustc --explain E0425` to see a detailed explanation
foo.rs:6:5: 6:20 error: this function takes 0 parameters but 1 parameter was supplied [E0061]
foo.rs:6     bar(foo::bar());
             ^~~~~~~~~~~~~~~
foo.rs:6:5: 6:20 help: run `rustc --explain E0061` to see a detailed explanation
error: aborting due to previous error

Note that on stable this yields a message which is actionable and concise:

foo.rs:6:9: 6:17 error: unresolved name `foo::bar` [E0425]
foo.rs:6     bar(foo::bar());
                 ^~~~~~~~
foo.rs:6:9: 6:17 help: run `rustc --explain E0425` to see a detailed explanation
error: aborting due to previous error
@alexcrichton alexcrichton added the A-diagnostics Area: Messages for errors, warnings, and lints label Mar 1, 2016
@arielb1
Copy link
Contributor

arielb1 commented Mar 3, 2016

The type error is correct in your "minified" example - bar takes zero parameters and you passed one.

@alexcrichton
Copy link
Member Author

Guh right, sorry!

@nikomatsakis
Copy link
Contributor

I think this is a roughly minimized example:

trait TheTrait { }

fn closure<F, T>(x: F) -> Result<T, ()>
    where F: FnMut() -> T, T: TheTrait,
{
    unimplemented!()
}

fn foo() {
    try!(closure(|| bar(0 as *mut _))) // bar intentionally undefined
}

fn main() { }

For me it gets:

/home/nmatsakis/tmp/issue-31997.rs:10:21: 10:24 error: unresolved name `bar` [E0425]
/home/nmatsakis/tmp/issue-31997.rs:10     try!(closure(|| bar(0 as *mut _))) // bar intentionally undefined
                                                          ^~~
/home/nmatsakis/tmp/issue-31997.rs:10:5: 10:39 note: in this expansion of try! (defined in <std macros>)
/home/nmatsakis/tmp/issue-31997.rs:10:21: 10:24 help: run `rustc --explain E0425` to see a detailed explanation
<std macros>:5:8: 6:42 error: mismatched types:
 expected `()`,
    found `core::result::Result<_, _>`
(expected (),
    found enum `core::result::Result`) [E0308]
<std macros>:5 return $ crate:: result:: Result:: Err (
<std macros>:6 $ crate:: convert:: From:: from ( err ) ) } } )
/home/nmatsakis/tmp/issue-31997.rs:10:5: 10:39 note: in this expansion of try! (defined in <std macros>)
<std macros>:5:8: 6:42 help: run `rustc --explain E0308` to see a detailed explanation
/home/nmatsakis/tmp/issue-31997.rs:10:10: 10:17 error: the trait `TheTrait` is not implemented for the type `()` [E0277]
/home/nmatsakis/tmp/issue-31997.rs:10     try!(closure(|| bar(0 as *mut _))) // bar intentionally undefined
                                               ^~~~~~~
/home/nmatsakis/tmp/issue-31997.rs:10:5: 10:39 note: in this expansion of try! (defined in <std macros>)
/home/nmatsakis/tmp/issue-31997.rs:10:10: 10:17 help: run `rustc --explain E0277` to see a detailed explanation
/home/nmatsakis/tmp/issue-31997.rs:10:10: 10:17 note: required by `closure`
/home/nmatsakis/tmp/issue-31997.rs:10:25: 10:36 error: casting `usize` as `*mut _` is invalid
/home/nmatsakis/tmp/issue-31997.rs:10     try!(closure(|| bar(0 as *mut _))) // bar intentionally undefined
                                                              ^~~~~~~~~~~
/home/nmatsakis/tmp/issue-31997.rs:10:5: 10:39 note: in this expansion of try! (defined in <std macros>)
error: aborting due to 3 previous errors

@nikomatsakis
Copy link
Contributor

Note in particular that this includes:

/home/nmatsakis/tmp/issue-31997.rs:10:10: 10:17 error: the trait `TheTrait` is not implemented for the type `()` [E0277]

which is pretty wacky, since () is not really a useful anything there.

@nikomatsakis
Copy link
Contributor

(Making some progress on this.)

@alexcrichton
Copy link
Member Author

Another small example yields the errors:

foo.rs:16:19: 16:31 error: failed to resolve. Use of undeclared type or module `HashMap` [E0433]
foo.rs:16     let mut map = HashMap::new();
                            ^~~~~~~~~~~~
foo.rs:16:19: 16:31 help: run `rustc --explain E0433` to see a detailed explanation
foo.rs:16:19: 16:31 error: unresolved name `HashMap::new` [E0425]
foo.rs:16     let mut map = HashMap::new();
                            ^~~~~~~~~~~~
foo.rs:16:19: 16:31 help: run `rustc --explain E0425` to see a detailed explanation
foo.rs:33:25: 33:55 error: the type of this value must be known in this context
foo.rs:33         let mut entry = map.entry(instance.to_owned()).or_insert(Instance {
                                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
foo.rs:40:21: 40:30 error: the type of this value must be known in this context
foo.rs:40             assert!(entry.end.is_none());
                              ^~~~~~~~~
foo.rs:40:13: 40:42 note: in this expansion of assert! (defined in <std macros>)
error: aborting due to 2 previous errors

The first error:

failed to resolve. Use of undeclared type or module `HashMap`

is the only real error, everything else is just spurious after that

@nikomatsakis
Copy link
Contributor

My PR in #32258 doesn't really help those cases; I think I could get rid of those "type of this value must be known" errors easily enough, at least.

@nikomatsakis
Copy link
Contributor

@alexcrichton pushed a commit that changes the output for that test too:

issue-31997.rs:30:19: 30:31 error: failed to resolve. Use of undeclared type or module `HashMap` [E0433]
issue-31997.rs:30     let mut map = HashMap::new();
                                    ^~~~~~~~~~~~
issue-31997.rs:30:19: 30:31 help: run `rustc --explain E0433` to see a detailed explanation
issue-31997.rs:30:19: 30:31 error: unresolved name `HashMap::new` [E0425]
issue-31997.rs:30     let mut map = HashMap::new();
                                    ^~~~~~~~~~~~
issue-31997.rs:30:19: 30:31 help: run `rustc --explain E0425` to see a detailed explanation
error: aborting due to 2 previous errors

@alexcrichton
Copy link
Member Author

Thanks @nikomatsakis! I think that's basically where we were at in ancient times, I've seen that double error for things like foo::bar for ages (cc @jseyfried, feeling ambitious?)

@jseyfried
Copy link
Contributor

@alexcrichton Fixed, see #32789.

@alexcrichton
Copy link
Member Author

Awesome, thanks @jseyfried!

bors added a commit that referenced this issue Apr 22, 2016
Suppress fallback and ambiguity errors

If the infcx has observed other errors, then suppress both default type
parameter fallback (which can be unreliable, as the full constraint set
is not available) and errors related to unresovled
variables (annoyingly, integer type variables cannot currently be
unified with error, so that has to be a separate mechanism). Also add a
flag to `infcx` to allow us to independently indicate when we have
observed an error and hence should trigger this suppression mode.

Fixes #31997

cc @alexcrichton
r? @arielb1
Manishearth added a commit to Manishearth/rust that referenced this issue Apr 22, 2016
Suppress fallback and ambiguity errors

If the infcx has observed other errors, then suppress both default type
parameter fallback (which can be unreliable, as the full constraint set
is not available) and errors related to unresovled
variables (annoyingly, integer type variables cannot currently be
unified with error, so that has to be a separate mechanism). Also add a
flag to `infcx` to allow us to independently indicate when we have
observed an error and hence should trigger this suppression mode.

Fixes rust-lang#31997

cc @alexcrichton
r? @arielb1
bors added a commit that referenced this issue Apr 25, 2016
Suppress fallback and ambiguity errors

If the infcx has observed other errors, then suppress both default type
parameter fallback (which can be unreliable, as the full constraint set
is not available) and errors related to unresovled
variables (annoyingly, integer type variables cannot currently be
unified with error, so that has to be a separate mechanism). Also add a
flag to `infcx` to allow us to independently indicate when we have
observed an error and hence should trigger this suppression mode.

Fixes #31997

cc @alexcrichton
r? @arielb1
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
Projects
None yet
Development

No branches or pull requests

4 participants