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

Wrong help message for Vec::resize_with calls that constrain the Vec to a wrong type #116155

Closed
narpfel opened this issue Sep 25, 2023 · 1 comment · Fixed by #116158
Closed
Assignees
Labels
A-diagnostics Area: Messages for errors, warnings, and lints D-invalid-suggestion Diagnostics: A structured suggestion resulting in incorrect code. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@narpfel
Copy link
Contributor

narpfel commented Sep 25, 2023

Code

struct S { xs: Vec<usize> }

fn main() {
    let mut xs = Vec::new();
    xs.resize_with(42, || true);
    S { xs };
}

Current output

error[E0308]: mismatched types
 --> <source>:6:9
  |
5 |     xs.resize_with(42, || true);
  |     --                 ------- this argument has type `[closure@<source>:5:24: 5:26]`...
  |     |
  |     ... which causes `xs` to have type `Vec<bool>`
6 |     S { xs };
  |         ^^ expected `Vec<usize>`, found `Vec<bool>`
  |
  = note: expected struct `Vec<usize>`
             found struct `Vec<bool>`
help: use parentheses to call this closure
  |
5 |     xs.resize_with(42, (|| true)());
  |                        +       +++

error: aborting due to previous error

For more information about this error, try `rustc --explain E0308`.
Compiler returned: 1

Desired output

error[E0308]: mismatched types
 --> <source>:6:9
  |
5 |     xs.resize_with(42, || true);
  |     --                 ------- this argument has type `[closure@<source>:5:24: 5:26]`...
  |     |
  |     ... which causes `xs` to have type `Vec<bool>`
6 |     S { xs };
  |         ^^ expected `Vec<usize>`, found `Vec<bool>`
  |
  = note: expected struct `Vec<usize>`
             found struct `Vec<bool>`
help: this expression should have type `usize`
  |
5 |     xs.resize_with(42, || true);
  |                           ~~~~

error: aborting due to previous error

For more information about this error, try `rustc --explain E0308`.
Compiler returned: 1

Rationale and extra context

The same help message is also shown for function calls and other cases which later lead to type errors, such as returning xs from a function with return type Vec<usize>.

Present in 1.72.0 stable and nightly-2023-09-24:

$ rustc -vV
rustc 1.74.0-nightly (37390d656 2023-09-24)
binary: rustc
commit-hash: 37390d65636dd67e263753a3c04fbc60dcc4348e
commit-date: 2023-09-24
host: x86_64-unknown-linux-gnu
release: 1.74.0-nightly
LLVM version: 17.0.0

Other cases

No response

Anything else?

Godbolt link

@narpfel narpfel added A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Sep 25, 2023
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Sep 25, 2023
@saethlin saethlin added D-invalid-suggestion Diagnostics: A structured suggestion resulting in incorrect code. and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Sep 25, 2023
@asquared31415
Copy link
Contributor

Reduced to not rely on Vec:

struct S<T>(T);

impl<T> S<T> {
    fn new() -> Self {
        loop {}
    }

    fn constrain<F: Fn() -> T>(&self, _f: F) {}
}

fn main() {
    let s = S::new();
    let c = || true;
    s.constrain(c);
    let _: S<usize> = s;
}
error[E0308]: mismatched types
  --> src/main.rs:15:23
   |
14 |     s.constrain(c);
   |     -           - this argument has type `[closure@src/main.rs:13:13: 13:15]`...
   |     |
   |     ... which causes `s` to have type `S<bool>`
15 |     let _: S<usize> = s;
   |            --------   ^ expected `S<usize>`, found `S<bool>`
   |            |
   |            expected due to this
   |
   = note: expected struct `S<usize>`
              found struct `S<bool>`
help: use parentheses to call this closure
   |
14 |     s.constrain(c());
   |                  ++

@compiler-errors compiler-errors self-assigned this Sep 25, 2023
@bors bors closed this as completed in 634e5c9 Oct 3, 2023
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Oct 3, 2023
Rollup merge of rust-lang#116158 - compiler-errors:unconstrained-type-var-sugg, r=wesleywiser

Don't suggest nonsense suggestions for unconstrained type vars in `note_source_of_type_mismatch_constraint`

The way we do type inference for suggestions in `note_source_of_type_mismatch_constraint` is a bit strange. We compute the "ideal" method signature, which takes the receiver that we *want* and uses it to compute the types of the arguments that would have given us that receiver via type inference, and use *that* to suggest how to change an argument to make sure our receiver type is inferred correctly.

The problem is that sometimes we have totally unconstrained arguments (well, they're constrained by things outside of the type checker per se, like associated types), and therefore type suggestions are happy to coerce anything to that unconstrained argument. This leads to bogus suggestions, like rust-lang#116155. This is partly due to above, and partly due to the fact that `emit_type_mismatch_suggestions` doesn't double check that its suggestions are actually compatible with the program other than trying to satisfy the type mismatch.

This adds a hack to make sure that at least the types are fully constrained, but I guess I could also rip out this logic altogether. There would be some sad diagnostics regressions though, such as `tests/ui/type/type-check/point-at-inference-4.rs`.

Fixes rust-lang#116155
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 D-invalid-suggestion Diagnostics: A structured suggestion resulting in incorrect code. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
5 participants