-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Confusing "the caller chooses a type which can be different" [E308] #126547
Comments
@rustbot label +D-confusing |
Thanks, that note definitely doesn't make sense. I suggested to move We should replicate some parts of |
Thanks for the cc @fmease, I'll take a look ~today/tomorrow |
…ram" note - Avoid "caller chooses ty for type param" note if the found type a.k.a. the return expression type *contains* the type parameter, because e.g. `&T` will always be different from `T` (i.e. "well duh"). - Rename `note_caller_chooses_ty_for_ty_param` to `try_note_caller_chooses_ty_for_ty_param` because the note is not always made. Issue: rust-lang#126547
Opened #126558 to avoid making the note if found return type contains the expected return type (type parameter). |
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
…ram" note - Avoid "caller chooses ty for type param" note if the found type a.k.a. the return expression type *contains* the type parameter, because e.g. `&T` will always be different from `T` (i.e. "well duh"). - Rename `note_caller_chooses_ty_for_ty_param` to `try_note_caller_chooses_ty_for_ty_param` because the note is not always made. Issue: 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
Code
Current output
Desired output
Rationale and extra context
The statement "the caller chooses a type for
T
which can be different from&T
" is confusing becauseT
and&T
are always different. I think it would be best to supress that note when the types only differ in reference-ness. The message was introduced in #122195.Other cases
No response
Rust Version
Anything else?
No response
The text was updated successfully, but these errors were encountered: