-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Confusing "the caller chooses a type which can be different" [E308] #126547
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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: