-
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
Type inference error when accessing field #50692
Comments
Simplified example: fn main() {
let array = [0; 16];
let mut option = None;
if let Some(n) = option {
array[n];
array[n].to_le();
}
} Interestingly, this can be workarounded in the provided example by having |
What is happening is that because |
But |
To clarify, |
Ah ok, I think I (sort of) get it now. To be honest, I don't think how type inference works exactly needs to be mentioned in the error. (Basically, if it cannot infer the types in line X, I have no expectations for it to continue beyond that point.) What cost me some time, because it wasn't immediately obvious to me (the real code was a little bit more complicated than this minimal example), was that at first, I wasn't able to trace the error back to a specific variable. It would have helped immensely if the error message had been something along the lines of "cannot infer type of |
This PR improves the span of eager resolution type errors referring to indexing and field access to use the base span rather than the whole expression. Also a note "Type must be known at this point." is added to where we at some point in the past emitted the "type must be known at this context" error, so that early failures can be differentiated and will hopefully be less surprising. Fixes rust-lang#50692 (or at least does the best we can for the moment) r? @estebank
That's a good idea, but I think it would be complicated to implement. Hopefully with the chalk integration we will be able to make progress on the underlining issue. For now, I've changed the message:
To:
Hopefully the corrected span and the note will make things a bit less confusing. |
…n-error-message, r=estebank Improve eager type resolution error message This PR improves the span of eager resolution type errors referring to indexing and field access to use the base span rather than the whole expression. Also a "note: type must be known at this point" is added where in the past we emitted the "type must be known at this context" error, so that early failures can be differentiated and will hopefully be less surprising. Fixes rust-lang#50692 (or at least does the best we can for the moment) r? @estebank
…n-error-message, r=estebank Improve eager type resolution error message This PR improves the span of eager resolution type errors referring to indexing and field access to use the base span rather than the whole expression. Also a "note: type must be known at this point" is added where in the past we emitted the "type must be known at this context" error, so that early failures can be differentiated and will hopefully be less surprising. Fixes rust-lang#50692 (or at least does the best we can for the moment) r? @estebank
I was advised to open an issue here, so here goes:
I stumbled upon a strange compile error today, that I have minimized to the following example (Playground):
What's strange is that when I add a purposefully wrong type annotation like this:
the compiler correctly recognizes that
bool
is the wrong type and even tells me the correct type:However, as soon as I try to access a field, type inference fails. (Basically it knows that
array[n]
is of typeElement
, but later cannot infer the type ofarray[n].next
.)Is this a known limitation of type inference?
(EDIT: I'm aware that I can get rid of the compile error by adding a type annotation to the declaration of
option
. I'm just surprised by the behaviour of type inference in this example..)The text was updated successfully, but these errors were encountered: