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

rustc_typeck: don't expect rvalues to have unsized types. #20083

Merged
merged 1 commit into from
Dec 23, 2014

Conversation

eddyb
Copy link
Member

@eddyb eddyb commented Dec 20, 2014

This fixes a few corner cases with expected type propagation, e.g.:

fn take_int_slice(_: &[int]) {}
take_int_slice(&if 1 < 0 { [ 0, 1 ] } else { [ 0, 1 ] });
<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.

@rust-highfive
Copy link
Collaborator

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

@eddyb
Copy link
Member Author

eddyb commented Dec 20, 2014

cc @steveklabnik who might have been hitting this bug in rustbook.

@alexcrichton
Copy link
Member

r? @nikomatsakis

@flaper87
Copy link
Contributor

@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.

@nikomatsakis
Copy link
Contributor

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.)

bors added a commit that referenced this pull request Dec 23, 2014
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.
@bors bors merged commit adabf4e into rust-lang:master Dec 23, 2014
@eddyb eddyb deleted the fix-expectation branch December 23, 2014 20:24
bors added a commit that referenced this pull request Feb 14, 2016
Handles `str` being an expression's expected type, which was missing from #20083.
Fixes #26978.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Rvalues are incorrectly expected to have unsized types.
6 participants