-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Propagate coercion cause into try_coerce
#89028
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
Conversation
Currently, `coerce_inner` discards its `ObligationCause` when calling `try_coerce`. This interfers with other diagnostc improvements I'm working on, since we will lose the original span by the time the actual coercion occurs. Additionally, we now use the span of the trailing expression (rather than the span of the entire function) when performing a coercion in `check_return_expr`. This currently has no visible effect on any of the unit tests, but will unblock future diagnostic improvements.
r? @nagisa (rust-highfive has picked a reviewer for you, use r? to override) |
@bors try @rust-timer queue inference perf can easily be regressed by innocent changes, let's check that first |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 31cdd8c with merge 9a02d2019558beb5eb9dcb801d3d4e86ea21c3b4... |
☀️ Try build successful - checks-actions |
Queued 9a02d2019558beb5eb9dcb801d3d4e86ea21c3b4 with parent 78a46ef, future comparison URL. |
Finished benchmarking commit (9a02d2019558beb5eb9dcb801d3d4e86ea21c3b4): comparison url. Summary: This benchmark run did not return any relevant changes. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf. @bors rollup=never |
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.
Looks like a good improvement.
let mut span = return_expr.span; | ||
// Use the span of the trailing expression for our cause, | ||
// not the span of the entire function | ||
if !explicit_return { |
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.
Is it actually necessary to have the boolean flag here? I imagine it is trying to account for something like
return { foo; bar; baz };
so that rustc would span the entire block and not just baz
here? It seems to me that it would be actually better, and more consistent if we spanned the last expression of the block in these situations.
@bors r+ |
📌 Commit 31cdd8c has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (3bca723): comparison url. Summary: This benchmark run did not return any relevant changes. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
Currently,
coerce_inner
discards itsObligationCause
when calling
try_coerce
. This interfers with otherdiagnostc improvements I'm working on, since we will lose
the original span by the time the actual coercion occurs.
Additionally, we now use the span of the trailing expression
(rather than the span of the entire function) when performing
a coercion in
check_return_expr
. This currently has no visibleeffect on any of the unit tests, but will unblock future
diagnostic improvements.