-
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
rustc_typeck: don't expect rvalues to have unsized types. #20083
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
cc @steveklabnik who might have been hitting this bug in rustbook. |
@eddyb it'd be nice if you could write a more descriptive commit message for this change or at least open a bug with a description so it's clear what's wrong here and what bug you're trying to fix. |
6de9f9f
to
87f39e9
Compare
87f39e9
to
575f05e
Compare
r+ modulo nits This new version is so much better than the old one indeed. And it might be nice to open an issue on the problem you are encountering, just so that you can cite it from the code and leave a paper trail as to what is happening here. (I've found I love encountering issue numbers in the source, so that I can go read up.) |
575f05e
to
adabf4e
Compare
This fixes a few corner cases with expected type propagation, e.g.: ```rust fn take_int_slice(_: &[int]) {} take_int_slice(&if 1 < 0 { [ 0, 1 ] } else { [ 0, 1 ] }); ``` ```rust <anon>:2:28: 2:36 error: mismatched types: expected `[int]`, found `[int, ..2]` <anon>:2 take_int_slice(&if 1 < 0 { [ 0, 1 ] } else { [ 0, 1 ] }); ^~~~~~~~ <anon>:2:46: 2:54 error: mismatched types: expected `[int]`, found `[int, ..2]` <anon>:2 take_int_slice(&if 1 < 0 { [ 0, 1 ] } else { [ 0, 1 ] }); ^~~~~~~~ ``` Right now we unpack the expected `&[int]` and pass down `[int]`, forcing rvalue expressions to take unsized types, which causes mismatch errors. Instead, I replaced that expectation with a weaker hint, for the unsized cases - a hint is still required to infer the integer literals' types, above. Fixes #20169.
This fixes a few corner cases with expected type propagation, e.g.:
Right now we unpack the expected
&[int]
and pass down[int]
, forcingrvalue expressions to take unsized types, which causes mismatch errors.
Instead, I replaced that expectation with a weaker hint, for the unsized
cases - a hint is still required to infer the integer literals' types, above.
Fixes #20169.