-
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
Suggest adding return
if the for semi which can coerce to the fn return type
#115196
Conversation
ed3e9f6
to
af377c6
Compare
af377c6
to
c381f8f
Compare
c381f8f
to
a7bf3aa
Compare
2fbc863
to
f1cf816
Compare
gonna pass this over to esteban for advice on the wording, impl looks fine enough (a bit hacky, but oh well) r? estebank |
Could not assign reviewer from: |
f1cf816
to
f0c6f00
Compare
☔ The latest upstream changes (presumably #115696) made this pull request unmergeable. Please resolve the merge conflicts. |
f0c6f00
to
8f0665f
Compare
| | ||
LL | Err::<T, MyError>(MyError); | ||
| ++++++++++++++ | ||
help: you might have meant to return this to infer its type parameters |
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.
I wonder if it would make sense to just ask did you mean to return this?
At least in the examples here, forgetting to write return
is probably a bigger deal to the user than needing to qualify the type.
Just a thought 🙂
☔ The latest upstream changes (presumably #114811) made this pull request unmergeable. Please resolve the merge conflicts. |
8f0665f
to
a204ada
Compare
self.err_ctxt().report_fulfillment_errors(errors); | ||
self.collect_unused_stmts_for_coerce_return_ty(errors_causecode); |
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.
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, I see what's going on, report_fulfillment_errors
now takes ownership, a change I made purely because we never needed access to the errors after reporting before this change.
Would it be feasible to instead modify the error cause code to carry an Option<Span>
for the place where the return
would be suggested? That way we don't need to leverage the "steal" mechanism nor clone the errors only iterate over them. We do something similar for errors coming from type parameters or from function arguments.
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.
Do you mean to add a field Option<span>
to ExprBindingObligation
, then use ObligationCause
's map_code
API to update the trigger span?
I tried this solution and seems involve a wider change, and end with that we can not get the diag
here if we don't use the "steal" mechanism:
diag.span_suggestion_verbose( |
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.
I'm ok with the code. I'd prefer to avoid the errors_causecode
cloning, but if my proposed alternative to modify the errors
in-place proves to be infeasible, we can go with that (after all, we are already in the unhappy path, this won't impact compile times).
self.err_ctxt().report_fulfillment_errors(errors); | ||
self.collect_unused_stmts_for_coerce_return_ty(errors_causecode); |
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, I see what's going on, report_fulfillment_errors
now takes ownership, a change I made purely because we never needed access to the errors after reporting before this change.
Would it be feasible to instead modify the error cause code to carry an Option<Span>
for the place where the return
would be suggested? That way we don't need to leverage the "steal" mechanism nor clone the errors only iterate over them. We do something similar for errors coming from type parameters or from function arguments.
…oerce to the fn return type
a204ada
to
25d38c4
Compare
@bors r+ |
…iaskrgr Rollup of 3 pull requests Successful merges: - rust-lang#115196 (Suggest adding `return` if the for semi which can coerce to the fn return type) - rust-lang#115955 (Stabilize `{IpAddr, Ipv6Addr}::to_canonical`) - rust-lang#116776 (Enable `review-requested` feature for rustbot) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#115196 - chenyukang:yukang-fix-86094, r=estebank Suggest adding `return` if the for semi which can coerce to the fn return type Fixes rust-lang#86094 r? `@estebank`
54: Pull upstream master 2023 10 17 r=pietroalbini a=Veykril * rust-lang/rust#116196 * rust-lang/rust#116824 * rust-lang/rust#116822 * rust-lang/rust#116477 * rust-lang/rust#116826 * rust-lang/rust#116820 * rust-lang/rust#116811 * rust-lang/rust#116808 * rust-lang/rust#116805 * rust-lang/rust#116800 * rust-lang/rust#116798 * rust-lang/rust#116754 * rust-lang/rust#114370 * rust-lang/rust#116804 * rust-lang/rust#116802 * rust-lang/rust#116790 * rust-lang/rust#116786 * rust-lang/rust#116709 * rust-lang/rust#116430 * rust-lang/rust#116257 * rust-lang/rust#114157 * rust-lang/rust#116731 * rust-lang/rust#116550 * rust-lang/rust#114330 * rust-lang/rust#116724 * rust-lang/rust#116782 * rust-lang/rust#116776 * rust-lang/rust#115955 * rust-lang/rust#115196 * rust-lang/rust#116775 * rust-lang/rust#114589 * rust-lang/rust#113747 * rust-lang/rust#116772 * rust-lang/rust#116771 * rust-lang/rust#116760 * rust-lang/rust#116755 * rust-lang/rust#116732 * rust-lang/rust#116522 * rust-lang/rust#116341 * rust-lang/rust#116172 * rust-lang/rust#110604 * rust-lang/rust#110729 * rust-lang/rust#116527 * rust-lang/rust#116688 * rust-lang/rust#116757 * rust-lang/rust#116753 * rust-lang/rust#116748 * rust-lang/rust#116741 * rust-lang/rust#116594 * rust-lang/rust#116691 * rust-lang/rust#116643 * rust-lang/rust#116683 * rust-lang/rust#116635 * rust-lang/rust#115515 * rust-lang/rust#116742 * rust-lang/rust#116661 * rust-lang/rust#116576 * rust-lang/rust#116540 * rust-lang/rust#116352 * rust-lang/rust#116737 * rust-lang/rust#116730 * rust-lang/rust#116723 * rust-lang/rust#116715 * rust-lang/rust#116603 * rust-lang/rust#116591 * rust-lang/rust#115439 * rust-lang/rust#116264 * rust-lang/rust#116727 * rust-lang/rust#116704 * rust-lang/rust#116696 * rust-lang/rust#116695 * rust-lang/rust#116644 * rust-lang/rust#116630 * rust-lang/rust#116728 * rust-lang/rust#116689 * rust-lang/rust#116679 * rust-lang/rust#116618 * rust-lang/rust#116577 * rust-lang/rust#115653 * rust-lang/rust#116702 * rust-lang/rust#116015 * rust-lang/rust#115822 * rust-lang/rust#116407 * rust-lang/rust#115719 * rust-lang/rust#115524 * rust-lang/rust#116705 * rust-lang/rust#116645 * rust-lang/rust#116233 * rust-lang/rust#115108 * rust-lang/rust#116670 * rust-lang/rust#116676 * rust-lang/rust#116666 Co-authored-by: Benoît du Garreau <bdgdlm@outlook.com> Co-authored-by: Colin Finck <colin@reactos.org> Co-authored-by: Ian Jackson <ijackson@chiark.greenend.org.uk> Co-authored-by: Joshua Liebow-Feeser <joshlf@users.noreply.github.com> Co-authored-by: León Orell Valerian Liehr <me@fmease.dev> Co-authored-by: Trevor Gross <tmgross@umich.edu> Co-authored-by: Evan Merlock <evan@merlock.dev> Co-authored-by: joboet <jonasboettiger@icloud.com> Co-authored-by: Ralf Jung <post@ralfj.de> Co-authored-by: DaniPopes <57450786+DaniPopes@users.noreply.github.com> Co-authored-by: Mark Rousskov <mark.simulacrum@gmail.com> Co-authored-by: onur-ozkan <work@onurozkan.dev> Co-authored-by: Nicholas Nethercote <n.nethercote@gmail.com> Co-authored-by: The 8472 <git@infinite-source.de> Co-authored-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Co-authored-by: reez12g <reez12g@gmail.com> Co-authored-by: Jakub Beránek <berykubik@gmail.com>
Fixes #86094
r? @estebank