Skip to content

Compiler guesses incorrect type after error occurs #76589

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

Closed
Aaron1011 opened this issue Sep 11, 2020 · 0 comments · Fixed by #106199
Closed

Compiler guesses incorrect type after error occurs #76589

Aaron1011 opened this issue Sep 11, 2020 · 0 comments · Fixed by #106199
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-inference Area: Type inference D-verbose Diagnostics: Too much output caused by a single piece of incorrect code.

Comments

@Aaron1011
Copy link
Member

The following code:

fn main() {
    let a = String::missing_method();
    let b: &str = &a;
    let c: String = a;
}

prints the following error messages:

error[E0599]: no function or associated item named `missing_method` found for struct `std::string::String` in the current scope
 --> src/main.rs:2:21
  |
2 |     let a = String::missing_method();
  |                     ^^^^^^^^^^^^^^ function or associated item not found in `std::string::String`

error[E0308]: mismatched types
 --> src/main.rs:4:21
  |
4 |     let c: String = a;
  |            ------   ^
  |            |        |
  |            |        expected struct `std::string::String`, found `str`
  |            |        help: try using a conversion method: `a.to_string()`
  |            expected due to this

error: aborting due to 2 previous errors

The compiler appears to have inferred the type of a to be str, based on the statement let b: &str = &a. However, this is almost certainly the wrong thing to do. The fact that an error occurred while type-checking the initial declaration means that we cannot be sure of what type the user intended to use. In this case, unifying &str with &a produces an incorrect type of a, since a deref coercion will likely be involved in the corrected code (e.g. if the user writes let a = String::new()).

We should be more cautious about inferring the types of locals when an error has occurred. If we are certain that no coercions can be occurring (e.g. passing a to a function that takes a String parameter), then continuing on to infer the variable's type should be fine.

@Aaron1011 Aaron1011 added A-diagnostics Area: Messages for errors, warnings, and lints A-inference Area: Type inference D-verbose Diagnostics: Too much output caused by a single piece of incorrect code. labels Sep 11, 2020
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Dec 28, 2022
…, r=compiler-errors

Silence knock-down errors on `[type error]` bindings

Fix rust-lang#56036, fix rust-lang#76589.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Dec 28, 2022
…, r=compiler-errors

Silence knock-down errors on `[type error]` bindings

Fix rust-lang#56036, fix rust-lang#76589.
@bors bors closed this as completed in 8e039b6 Dec 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-inference Area: Type inference D-verbose Diagnostics: Too much output caused by a single piece of incorrect code.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant