-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
E0593 regression when mismatched argument count leads to other errors in Beta/Nightly #47244
Comments
triage: P-high |
I don't think the presentation changes that that PR (and the one it's supplementing) introduced. It looks to me that it doesn't actually get to check |
@estebank great, if you don't have time, lemme know |
@nikomatsakis I didn't have time to look into this and will unlikely have time to perform a bisect during the week. I can confirm that this was introduced earlier than #47747. |
cc @rust-lang/compiler -- can somebody pick this up to try and get to the bottom of it? |
Bisection result is #45879. Test script: #!/bin/sh
$RUSTC_RELATIVE -V
! ( $RUSTC_RELATIVE 1.rs 2>&1 | grep E0593 )
Output:
|
D'oh, that's my pr :) |
I wonder if this really broke in 053383d...? at least, when I trace what's happening, that seems to be where it goes wrong. But I guess the bisection doesn't lie. |
Anyway I think the problem roughly is here: rust/src/librustc_typeck/check/closure.rs Lines 419 to 422 in 932c736
This corresponds to the case where (a) we figured out from context that the fn needs N parameters but (b) it is declared with M parameters. As you can see from the comment, "we could probably handle this case more gracefully". What we do now is to ignore the expectations and just give those parameters "unknown types". I'm not sure yet the best way to fix this -- we could certainly report a useful error here, we have a lot of the information we want. But then I think we might get duplicate errors. We could perhaps report an error and then give the parameters the type of Hmm, that's probably best. |
As a user, the "Type must be known at compile time" error just ends up being confusing as that makes me search for ways to annotate the type, which is just wasted effort - so reporting the first error and skipping the second error might actually be better than reporting both issues. |
@nikomatsakis for what is worth, I don't think we're taking advantage of |
I have a fix. |
Something weird happened with git but once I get that straightened out, will open a PR. |
…um-args, r=estebank detect wrong number of args when type-checking a closure Instead of creating inference variables for those argument types, use the trait error-reporting code to give a nicer error. This also improves some other spans for existing tests. Fixes rust-lang#47244 r? @estebank
…um-args, r=estebank detect wrong number of args when type-checking a closure Instead of creating inference variables for those argument types, use the trait error-reporting code to give a nicer error. This also improves some other spans for existing tests. Fixes rust-lang#47244 r? @estebank
…um-args, r=estebank detect wrong number of args when type-checking a closure Instead of creating inference variables for those argument types, use the trait error-reporting code to give a nicer error. This also improves some other spans for existing tests. Fixes rust-lang#47244 r? @estebank
Playground
Commenting out the
b.to_string()
will yield the[E0593]
error in all toolchains.The
[E0619]
alone makes for a very confusing error message, as the user's assumption is that the type ofb
is correct.The text was updated successfully, but these errors were encountered: