-
Notifications
You must be signed in to change notification settings - Fork 13.3k
ICE: Computing fictitious types #6319
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
Comments
+1, I'm running into this, too. |
in my case, it turned out to be a missing ampersand on the pattern match for the tuple. I spent a bit of time digging around in the compiler to figure out whether it would be possible to at least attach some span info to the error message, but I came up empty. |
This seems like a missing error report to me. Clearly these programs should not be type checking, and those ICEs I believe come from passes that follow type checking. Perhaps an over-suppressed error? |
nominating for Production Ready |
I found this error in a different context, and another ICE in a related context (both for code that shouldn't pass the type checker):
|
I've fixed this in a branch. Just testing now. |
In rust-lang#6319, several people mentioned they ran into a "computing fictitious type" ICE in trans. This turns out to be because some of my recent changes to typeck::check::_match resulted in type errors getting reported with ty_err as the expected type, which meant the errors were suppressed, and typechecking incorrectly succeeded (since the errors weren't recorded). Changed the error messages in these cases not to use an expected type at all, rather, printing out a string describing the type that was expected (which is what the code originally did). The result is a bit repetitive and the proliferation of error-reporting functions in typeck::infer is a bit annoying, but I thought it was important to fix this now; more cleanup can happen later.
Fixed pending #6427 |
r? @nikomatsakis In #6319, several people mentioned they ran into a "computing fictitious type" ICE in trans. This turns out to be because some of my recent changes to typeck::check::_match resulted in type errors getting reported with ty_err as the expected type, which meant the errors were suppressed, and typechecking incorrectly succeeded (since the errors weren't recorded). Changed the error messages in these cases not to use an expected type at all, rather, printing out a string describing the type that was expected (which is what the code originally did). The result is a bit repetitive and the proliferation of error-reporting functions in typeck::infer is a bit annoying, but I thought it was important to fix this now; more cleanup can happen later.
Fixed in 638b394 |
Rustup changelog: none r? `@ghost`
This program
generates:
Additionally, a similar program
yields
The text was updated successfully, but these errors were encountered: