-
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
Note that the caller chooses a type for type param #122195
Conversation
5cdde1c
to
99d6193
Compare
This comment has been minimized.
This comment has been minimized.
99d6193
to
7852895
Compare
@@ -1010,6 +1010,11 @@ impl<'a, 'tcx> FnCtxt<'a, 'tcx> { | |||
format!("impl {all_bounds_str}"), | |||
Applicability::MaybeIncorrect, | |||
); | |||
|
|||
err.note(format!( | |||
"the caller chooses the type of {} which can be different from {}", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"the caller chooses the type of {} which can be different from {}", | |
"the caller chooses a type for `{}` which can be different from `{}`", |
Backticks & “type for” over “type of”. The former is more precise semantically: T
stands for a type and can't be of a type, it's a type itself. Cf. the statement i32
is the type of 0i32
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Make sense, changed the wording to this.
This comment has been minimized.
This comment has been minimized.
(I think these are literally the only two tests that test this diagnostic) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! One last thing, could you please squash the commits into one? Then r=me
@bors rollup |
@bors delegate+ |
27774a0
to
a29ac16
Compare
@@ -889,7 +889,7 @@ impl<'a, 'tcx> FnCtxt<'a, 'tcx> { | |||
self.dcx(), | |||
errors::ExpectedReturnTypeLabel::Other { span: hir_ty.span, expected }, | |||
); | |||
self.try_suggest_return_impl_trait(err, expected, ty, fn_id); | |||
self.try_suggest_return_impl_trait(err, expected, found, fn_id); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually I wonder if we should add this note in more cases, not just in cases where we suggest RPITs. For example here:
fn f<T>() -> (T,) {
(0,)
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wait how do u undo a r=
lol (if you want me to add it in more places in this PR)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, let's do this!
Like this: |
0f368e3
to
eb7bbe8
Compare
Changes since last review:
@rustbot ready |
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
(One sec I forgot to bless some tests) |
09c1667
to
61d5d33
Compare
@@ -14,6 +14,7 @@ LL | u | |||
found type parameter `X` | |||
= note: a type parameter was expected, but a different one was found; you might be missing a type parameter or trait bound | |||
= note: for more information, visit https://doc.rust-lang.org/book/ch10-02-traits.html#traits-as-parameters | |||
= note: the caller chooses a type for `Self` which can be different from `X` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, this one is interesting. The note is technically speaking correct but I don't know if it helps the user. Remember that we add the note “the caller chooses …” because the user might not understand that fn f<T>() -> T
doesn't mean “can return anything the callee / the author of the function wants to return”. What do you think? Do you think it's useful?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This note doesn't seem very helpful in this instance, no. This particular case probably needs a separate note suggesting that X
might not satisfy X: Sized
but Self: Sized
or something to that effect. Not entirely sure what help to give here though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's not block this PR on this (given the long history of this diagnostic change with several failed PRs), we should probably not emit the note if the param is kw::SelfUpper
but that can be done in a follow up.
Sorry for the delay, I was sitting at my desk wondering why we're not suggesting impl-Trait on fn f<T>() -> (T,) { (0,) }
etc. (so, fn f() -> (impl Sized,) { (0,) }
which works perfectly). I should probably open an issue for that. If we end up making try_suggest_return_impl_trait
smarter at some point we can then probably also move the note back into impl-Trait since it does some other checks, too, which we don't do for note_caller_chooses_ty_for_ty_param
.
suggesting that X might not satisfy X: Sized but Self: Sized or something to that effect
Nah, that's not relevant here. The Sized
bounds only exist to allow the method to return self
.
This comment has been minimized.
This comment has been minimized.
61d5d33
to
cacdf92
Compare
Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
Let's merge this. This should probably be further tweaked over time (like maybe making the heuristics stricter) but I don't want to block this. @bors r+ rollup |
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#114009 (compiler: allow transmute of ZST arrays with generics) - rust-lang#122195 (Note that the caller chooses a type for type param) - rust-lang#122651 (Suggest `_` for missing generic arguments in turbofish) - rust-lang#122784 (Add `tag_for_variant` query) - rust-lang#122839 (Split out `PredicatePolarity` from `ImplPolarity`) - rust-lang#122873 (Merge my contributor emails into one using mailmap) - rust-lang#122885 (Adjust better spastorino membership to triagebot's adhoc_groups) - rust-lang#122888 (add a couple more tests) r? `@ghost` `@rustbot` modify labels: rollup
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#114009 (compiler: allow transmute of ZST arrays with generics) - rust-lang#122195 (Note that the caller chooses a type for type param) - rust-lang#122651 (Suggest `_` for missing generic arguments in turbofish) - rust-lang#122784 (Add `tag_for_variant` query) - rust-lang#122839 (Split out `PredicatePolarity` from `ImplPolarity`) - rust-lang#122873 (Merge my contributor emails into one using mailmap) - rust-lang#122885 (Adjust better spastorino membership to triagebot's adhoc_groups) - rust-lang#122888 (add a couple more tests) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#122195 - jieyouxu:impl-return-note, r=fmease Note that the caller chooses a type for type param ``` error[E0308]: mismatched types --> $DIR/return-impl-trait.rs:23:5 | LL | fn other_bounds<T>() -> T | - - | | | | | expected `T` because of return type | | help: consider using an impl return type: `impl Trait` | expected this type parameter ... LL | () | ^^ expected type parameter `T`, found `()` | = note: expected type parameter `T` found unit type `()` = note: the caller chooses the type of T which can be different from () ``` Tried to see if "expected this type parameter" can be replaced, but that goes all the way to `rustc_infer` so seems not worth the effort and can affect other diagnostics. Revives rust-lang#112088 and rust-lang#104755.
Note that the caller chooses a type for type param ``` error[E0308]: mismatched types --> $DIR/return-impl-trait.rs:23:5 | LL | fn other_bounds<T>() -> T | - - | | | | | expected `T` because of return type | | help: consider using an impl return type: `impl Trait` | expected this type parameter ... LL | () | ^^ expected type parameter `T`, found `()` | = note: expected type parameter `T` found unit type `()` = note: the caller chooses the type of T which can be different from () ``` Tried to see if "expected this type parameter" can be replaced, but that goes all the way to `rustc_infer` so seems not worth the effort and can affect other diagnostics. Revives rust-lang#112088 and rust-lang#104755.
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#114009 (compiler: allow transmute of ZST arrays with generics) - rust-lang#122195 (Note that the caller chooses a type for type param) - rust-lang#122651 (Suggest `_` for missing generic arguments in turbofish) - rust-lang#122784 (Add `tag_for_variant` query) - rust-lang#122839 (Split out `PredicatePolarity` from `ImplPolarity`) - rust-lang#122873 (Merge my contributor emails into one using mailmap) - rust-lang#122885 (Adjust better spastorino membership to triagebot's adhoc_groups) - rust-lang#122888 (add a couple more tests) r? `@ghost` `@rustbot` modify labels: rollup
hir_typeck: be more conservative in making "note caller chooses ty param" note In rust-lang#122195 I added a "caller chooses ty for type param" note for when the return expression type a.k.a. found type does not match the expected return type. rust-lang#126547 found that this note was confusing when the found return type *contains* the expected type, e.g. ```rs fn f<T>(t: &T) -> T { t } ``` because the found return type `&T` will *always* be different from the expected return type `T`, so the note was needlessly redundant and confusing. This PR addresses that by not making the note if the found return type contains the expected return type. r? `@fmease` (since you reviewed the original PR) Fixes rust-lang#126547
hir_typeck: be more conservative in making "note caller chooses ty param" note In rust-lang#122195 I added a "caller chooses ty for type param" note for when the return expression type a.k.a. found type does not match the expected return type. rust-lang#126547 found that this note was confusing when the found return type *contains* the expected type, e.g. ```rs fn f<T>(t: &T) -> T { t } ``` because the found return type `&T` will *always* be different from the expected return type `T`, so the note was needlessly redundant and confusing. This PR addresses that by not making the note if the found return type contains the expected return type. r? `@fmease` (since you reviewed the original PR) Fixes rust-lang#126547
hir_typeck: be more conservative in making "note caller chooses ty param" note In rust-lang#122195 I added a "caller chooses ty for type param" note for when the return expression type a.k.a. found type does not match the expected return type. rust-lang#126547 found that this note was confusing when the found return type *contains* the expected type, e.g. ```rs fn f<T>(t: &T) -> T { t } ``` because the found return type `&T` will *always* be different from the expected return type `T`, so the note was needlessly redundant and confusing. This PR addresses that by not making the note if the found return type contains the expected return type. r? ``@fmease`` (since you reviewed the original PR) Fixes rust-lang#126547
Rollup merge of rust-lang#126558 - jieyouxu:caller-chooses-ty, r=fmease hir_typeck: be more conservative in making "note caller chooses ty param" note In rust-lang#122195 I added a "caller chooses ty for type param" note for when the return expression type a.k.a. found type does not match the expected return type. rust-lang#126547 found that this note was confusing when the found return type *contains* the expected type, e.g. ```rs fn f<T>(t: &T) -> T { t } ``` because the found return type `&T` will *always* be different from the expected return type `T`, so the note was needlessly redundant and confusing. This PR addresses that by not making the note if the found return type contains the expected return type. r? ``@fmease`` (since you reviewed the original PR) Fixes rust-lang#126547
Tried to see if "expected this type parameter" can be replaced, but that goes all the way to
rustc_infer
so seems not worth the effort and can affect other diagnostics.Revives #112088 and #104755.