Emit a hint for bad call return types due to generic arguments #106752
Conversation
|
r? @TaKO8Ki (rustbot has picked a reviewer for you, use r? to override) |
rustbot
added
S-waiting-on-review
|
r? @estebank |
| match parent_expr.kind { | ||
| hir::ExprKind::Call(fun, args) => { | ||
| let hir::ExprKind::Path(hir::QPath::Resolved(_, path)) = fun.kind else { return; }; | ||
| let hir::def::Res::Def(_kind, def_id) = path.res else { return; }; |
There was a problem hiding this comment.
To filter the enum variants and tuple structs away you could look at _kind here to see that it is not a Ctor ("constructor"), but I'm seeing some cases where this note helps.
There was a problem hiding this comment.
Yeah, I'm torn on this as well because it's wide-reaching, but it does help in some cases because constructors are prone to hit the same confusing errors as regular function calls.
| LL | let _: Option<(i32,)> = Some(5_usize); | ||
| | ^^^^^-------^ | ||
| | | | ||
| | this argument influences the return type of `Some` |
There was a problem hiding this comment.
Maybe what we should do is tweak the wording depending on the item type? Because I'm sure people are going to be confused by talking about the "return type of an enum variant". Seeing tuple structs as functions is natural from the compiler's point of view, but not from the users'.
There was a problem hiding this comment.
I've put something in that tweaks the wording. It's slightly awkward for constructors, because they return a type that's different from the argument, and I don't know if there is a reliable way of getting that type regardless of wrapping, but this now is at least coherent.
When the return type of a function call depends on the type of an
argument, e.g.
```
fn foo<T>(x: T) -> T {
x
}
```
and the expected type is set due to either an explicitly typed
binding, or because the call to the function is in a tail position
without semicolon, the current error implies that the argument in the
call has the wrong type.
This new hint highlights that the expected type doesn't match the
returned type, which matches the argument type, and that that's why
we're flagging the argument type.
Fixes rust-lang#43608.
|
@bors r+ |
bors
added
S-waiting-on-bors
| help: the type constructed contains `()` due to the type of the argument passed | ||
| --> $DIR/issue-84128.rs:13:9 | ||
| | | ||
| LL | Foo(()) | ||
| | ^^^^--^ | ||
| | | | ||
| | this argument influences the type of `Foo` |
There was a problem hiding this comment.
I'm noticing that there are some cases where the existing machinery to detect the source of expectations isn't as robust as we'd like, but that's independent of this PR.
| help: the type constructed contains `{integer}` due to the type of the argument passed | ||
| --> $DIR/args-instead-of-tuple-errors.rs:6:34 | ||
| | | ||
| LL | let _: Option<(i32, bool)> = Some(1, 2); | ||
| | ^^^^^-^^^^ | ||
| | | | ||
| | this argument influences the type of `Some` |
There was a problem hiding this comment.
This case should probably have been silenced.
Emit a hint for bad call return types due to generic arguments
When the return type of a function call depends on the type of an argument, e.g.
```
fn foo<T>(x: T) -> T {
x
}
```
and the expected type is set due to either an explicitly typed binding, or because the call to the function is in a tail position without semicolon, the current error implies that the argument in the call has the wrong type.
This new hint highlights that the expected type doesn't match the returned type, which matches the argument type, and that that's why we're flagging the argument type.
Fixes rust-lang#43608.
Emit a hint for bad call return types due to generic arguments
When the return type of a function call depends on the type of an argument, e.g.
```
fn foo<T>(x: T) -> T {
x
}
```
and the expected type is set due to either an explicitly typed binding, or because the call to the function is in a tail position without semicolon, the current error implies that the argument in the call has the wrong type.
This new hint highlights that the expected type doesn't match the returned type, which matches the argument type, and that that's why we're flagging the argument type.
Fixes rust-lang#43608.
…iaskrgr Rollup of 10 pull requests Successful merges: - rust-lang#106046 (Fix mir-opt tests for big-endian platforms) - rust-lang#106470 (tidy: Don't include wasm32 in compiler dependency check) - rust-lang#106566 (Emit a single error for contiguous sequences of unknown tokens) - rust-lang#106644 (Update the wasi-libc used for the wasm32-wasi target) - rust-lang#106665 (Add note when `FnPtr` vs. `FnDef` impl trait) - rust-lang#106752 (Emit a hint for bad call return types due to generic arguments) - rust-lang#106788 (Tweak E0599 and elaborate_predicates) - rust-lang#106831 (Use GitHub yaml templates for ICE, Docs and Diagnostics tickets) - rust-lang#106846 (Improve some comments and names in parser) - rust-lang#106848 (Fix wrong path in triage bot autolabel for wg-trait-solver-refactor) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
When the return type of a function call depends on the type of an argument, e.g.
and the expected type is set due to either an explicitly typed binding, or because the call to the function is in a tail position without semicolon, the current error implies that the argument in the call has the wrong type.
This new hint highlights that the expected type doesn't match the returned type, which matches the argument type, and that that's why we're flagging the argument type.
Fixes #43608.