Use larger span for adjustment THIR expressions #89110

Aaron1011 · 2021-09-19T22:02:26Z

Currently, we use a relatively 'small' span for THIR
expressions generated by an 'adjustment' (e.g. an autoderef,
autoborrow, unsizing). As a result, if a borrow generated
by an adustment ends up causing a borrowcheck error, for example:

let mut my_var = String::new();
let my_ref = &my_var
my_var.push('a');
my_ref;

then the span for the mutable borrow may end up referring
to only the base expression (e.g. my_var), rather than
the method call which triggered the mutable borrow
(e.g. my_var.push('a'))

Due to a quirk of the MIR borrowck implementation,
this doesn't always get exposed in migration mode,
but it does in many cases.

This commit makes THIR building consistently use 'larger'
spans for adjustment expressions. These spans are recoded
when we first create the adjustment during typecheck. For
example, an autoref adjustment triggered by a method call
will record the span of the entire method call.

The intent of this change it make it clearer to users
when it's the specific way in which a variable is
used (for example, in a method call) that produdes
a borrowcheck error. For example, an error message
claiming that a 'mutable borrow occurs here' might
be confusing if it just points at a usage of a variable
(e.g. my_var), when no &mut is in sight. Pointing
at the entire expression should help to emphasize
that the method call itself is responsible for
the mutable borrow.

In several cases, this makes the #![feature(nll)] diagnostic
output match up exactly with the default (migration mode) output.
As a result, several .nll.stderr files end up getting removed
entirely.

rust-highfive · 2021-09-19T22:02:29Z

r? @wesleywiser

(rust-highfive has picked a reviewer for you, use r? to override)

Aaron1011 · 2021-09-19T22:02:36Z

r? @estebank

Aaron1011 · 2021-09-19T22:06:03Z

Note that we don't currently explain that an autoderef/autoborrow was the cause of the borrow that resulted in an error. Doing so would require tracking additional information about THIR expressions / MIR statements, since we can't otherwise distinguish between a user-written &mut_var, and an adjustment-generated autoref.

However, I don't think this change makes the situation any more confusing. Previously, a user might be lead to incorrectly ask "Why does writing my_var trigger a mutable reference". With this change, they will hopefully instead be lead to ask "Why does writing my_var.some_method() trigger a mutable reference", which is the right question to be asking.

estebank · 2021-09-22T14:06:27Z

r=me after fixing the tests

Aaron1011 · 2021-09-22T20:21:17Z

It looks like storing the additional span in Adjustment is causing a large number of new incr comp invalidations of typecheck results. I'll see if anything can be done about it.

estebank · 2021-09-23T11:45:38Z

If you somehow keep two spans around, I would love it if we could point at both the receiver and the call with different labels to maybe explain what's happening better, but that might be too involved for this PR.

bors · 2021-09-24T02:16:25Z

☔ The latest upstream changes (presumably #88804) made this pull request unmergeable. Please resolve the merge conflicts.

Aaron1011 · 2021-09-25T02:00:52Z

@bors try @rust-timer queue

rust-timer · 2021-09-25T02:00:53Z

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

bors · 2021-09-25T02:01:00Z

⌛ Trying commit f33117fb9d8b1559497dd8d617e088d08e6e3345 with merge ac898de96c454463a122001d8e531e7be605a152...

bors · 2021-09-25T03:22:13Z

☀️ Try build successful - checks-actions
Build commit: ac898de96c454463a122001d8e531e7be605a152 (ac898de96c454463a122001d8e531e7be605a152)

rust-timer · 2021-09-25T03:22:14Z

Queued ac898de96c454463a122001d8e531e7be605a152 with parent 043972f, future comparison URL.

rust-timer · 2021-09-25T08:45:44Z

Finished benchmarking commit (ac898de96c454463a122001d8e531e7be605a152): 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
@rustbot label: +S-waiting-on-review -S-waiting-on-perf -perf-regression

Currently, we use a relatively 'small' span for THIR expressions generated by an 'adjustment' (e.g. an autoderef, autoborrow, unsizing). As a result, if a borrow generated by an adustment ends up causing a borrowcheck error, for example: ```rust let mut my_var = String::new(); let my_ref = &my_var my_var.push('a'); my_ref; ``` then the span for the mutable borrow may end up referring to only the base expression (e.g. `my_var`), rather than the method call which triggered the mutable borrow (e.g. `my_var.push('a')`) Due to a quirk of the MIR borrowck implementation, this doesn't always get exposed in migration mode, but it does in many cases. This commit makes THIR building consistently use 'larger' spans for adjustment expressions The intent of this change it make it clearer to users when it's the specific way in which a variable is used (for example, in a method call) that produdes a borrowcheck error. For example, an error message claiming that a 'mutable borrow occurs here' might be confusing if it just points at a usage of a variable (e.g. `my_var`), when no `&mut` is in sight. Pointing at the entire expression should help to emphasize that the method call itself is responsible for the mutable borrow. In several cases, this makes the `#![feature(nll)]` diagnostic output match up exactly with the default (migration mode) output. As a result, several `.nll.stderr` files end up getting removed entirely.

Aaron1011 · 2021-09-25T15:01:59Z

@estebank: I rewrote the implementation entirely - only rustc_mir_build needs to be modified now. Also, I've decreased the scale of this change slightly - it now only applies to method calls, rather than all adjustments.

estebank · 2021-09-28T16:46:52Z

@bors r+

bors · 2021-09-29T03:06:17Z

⌛ Testing commit 4d66986 with merge 85de977ecd19afc104105755aba47eb2521d2347...

bors · 2021-09-29T07:21:18Z

💥 Test timed out

Aaron1011 · 2021-09-29T10:34:43Z

@bors retry

bors · 2021-09-29T20:56:37Z

⌛ Testing commit 4d66986 with merge 700edf49ebfdb401f007379f83aebd2d6c8cb752...

bors · 2021-09-29T21:01:09Z

💔 Test failed - checks-actions

rust-log-analyzer · 2021-09-29T21:16:56Z

The job x86_64-msvc-1 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

    Finished dev [unoptimized + debuginfo] target(s) in 0.28s
Set({"src/tools/tidy"}) not skipped for "bootstrap::test::Tidy" -- not in ["src/test/ui", "src/tools/linkchecker"]
Skipping Suite("src/test/ui") because it is excluded
Suite("src/test/run-pass-valgrind") not skipped for "bootstrap::test::RunPassValgrind" -- not in ["src/test/ui", "src/tools/linkchecker"]
thread 'main' panicked at '"lldb" "-P" failed Output { status: ExitStatus(ExitStatus(3221225781)), stdout: "", stderr: "" }', src\bootstrap\test.rs:1394:40
Build completed unsuccessfully in 0:00:01
Build completed unsuccessfully in 0:00:01
make: *** [Makefile:72: ci-subset-1] Error 1
---
Cleaning up orphan processes
Terminate orphan process: pid (6136) (node)
Terminate orphan process: pid (2848) (python)
Terminate orphan process: pid (2896) (sccache)
Terminate orphan process: pid (892) (vctip)

ehuss · 2021-09-29T21:43:29Z

@bors retry
Issue with Windows LLDB

Mark-Simulacrum · 2021-09-30T01:40:25Z

@bors treeclosed-

bors · 2021-09-30T01:40:33Z

⌛ Testing commit 4d66986 with merge 4aa7879...

bors · 2021-09-30T04:51:35Z

☀️ Test successful - checks-actions
Approved by: estebank
Pushing 4aa7879 to master...

rust-timer · 2021-09-30T06:28:56Z

Finished benchmarking commit (4aa7879): 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

…stment-error, r=oli-obk (re-)tighten sourceinfo span of adjustments in MIR Diagnostics rely on the spans of MIR statements being (approximately) correct in order to give suggestions relative to that span (i.e. `shrink_to_hi` and `shrink_to_lo`). I discovered that we're *intentionally* lowering THIR exprs with their parent expr's span if they come from adjustments that are due to a parent expression. While I understand why that may be desirable to demonstrate the relationship of an adjustment and the expression that requires it, it leads to 1. very verbose borrowck output 2. incorrect spans for suggestions Some diagnostics get around that by giving suggestions relative to other spans we've collected during MIR lowering, such as the span of the method's identifier (e.g. `name` in `.name()`), but this doesn't work too well when things come from desugaring. I assume it also has lead to numerous tweaks and complications to diagnostics code down the road, which this PR doesn't necessarily aim to fix but may open the gates to fixing later... The last three commits are simplifications due to the fact that we can assume that the move span actually points to what is being moved (and a test). This regressed in rust-lang#89110, which was debated somewhat in rust-lang#90286. cc `@Aaron1011` who originally made this change. r? diagnostics Fixes rust-lang#113547 Fixes rust-lang#111016

rust-highfive assigned wesleywiser Sep 19, 2021

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 19, 2021

rust-highfive assigned estebank and unassigned wesleywiser Sep 19, 2021

This comment has been minimized.

Sign in to view

Aaron1011 force-pushed the adjustment-span branch from df00c68 to 45b4d33 Compare September 19, 2021 22:14

This comment has been minimized.

Sign in to view

Aaron1011 force-pushed the adjustment-span branch from 45b4d33 to e489fb9 Compare September 22, 2021 18:27

This comment has been minimized.

Sign in to view

Aaron1011 force-pushed the adjustment-span branch from e489fb9 to f33117f Compare September 25, 2021 00:43

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Sep 25, 2021

rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Sep 25, 2021

Aaron1011 force-pushed the adjustment-span branch from f33117f to 4d66986 Compare September 25, 2021 15:00

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 28, 2021

bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Sep 29, 2021

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 29, 2021

bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Sep 29, 2021

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 29, 2021

bors added the merged-by-bors This PR was explicitly merged by bors. label Sep 30, 2021

bors merged commit 4aa7879 into rust-lang:master Sep 30, 2021

rustbot added this to the 1.57.0 milestone Sep 30, 2021

bors mentioned this pull request Sep 30, 2021

Remove redundant member-constraint check #89229

Merged

camelid mentioned this pull request Oct 26, 2021

regression: rustc suggests .as_ref() at incorrect location and other spans have regressed #90286

Closed

compiler-errors mentioned this pull request Jun 22, 2023

(re-)tighten sourceinfo span of adjustments in MIR #112945

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use larger span for adjustment THIR expressions #89110

Use larger span for adjustment THIR expressions #89110

Aaron1011 commented Sep 19, 2021

rust-highfive commented Sep 19, 2021

Aaron1011 commented Sep 19, 2021

Aaron1011 commented Sep 19, 2021 •

edited

Loading

This comment has been minimized.

This comment has been minimized.

estebank commented Sep 22, 2021

This comment has been minimized.

Aaron1011 commented Sep 22, 2021

estebank commented Sep 23, 2021

bors commented Sep 24, 2021

Aaron1011 commented Sep 25, 2021

rust-timer commented Sep 25, 2021

bors commented Sep 25, 2021

bors commented Sep 25, 2021

rust-timer commented Sep 25, 2021

rust-timer commented Sep 25, 2021

Aaron1011 commented Sep 25, 2021

estebank commented Sep 28, 2021

bors commented Sep 29, 2021

bors commented Sep 29, 2021

Aaron1011 commented Sep 29, 2021

bors commented Sep 29, 2021

bors commented Sep 29, 2021

rust-log-analyzer commented Sep 29, 2021

ehuss commented Sep 29, 2021

Mark-Simulacrum commented Sep 30, 2021

bors commented Sep 30, 2021

bors commented Sep 30, 2021

rust-timer commented Sep 30, 2021

Use larger span for adjustment THIR expressions #89110

Use larger span for adjustment THIR expressions #89110

Conversation

Aaron1011 commented Sep 19, 2021

rust-highfive commented Sep 19, 2021

Aaron1011 commented Sep 19, 2021

Aaron1011 commented Sep 19, 2021 • edited Loading

This comment has been minimized.

This comment has been minimized.

estebank commented Sep 22, 2021

This comment has been minimized.

Aaron1011 commented Sep 22, 2021

estebank commented Sep 23, 2021

bors commented Sep 24, 2021

Aaron1011 commented Sep 25, 2021

rust-timer commented Sep 25, 2021

bors commented Sep 25, 2021

bors commented Sep 25, 2021

rust-timer commented Sep 25, 2021

rust-timer commented Sep 25, 2021

Aaron1011 commented Sep 25, 2021

estebank commented Sep 28, 2021

bors commented Sep 29, 2021

bors commented Sep 29, 2021

Aaron1011 commented Sep 29, 2021

bors commented Sep 29, 2021

bors commented Sep 29, 2021

rust-log-analyzer commented Sep 29, 2021

ehuss commented Sep 29, 2021

Mark-Simulacrum commented Sep 30, 2021

bors commented Sep 30, 2021

bors commented Sep 30, 2021

rust-timer commented Sep 30, 2021

Aaron1011 commented Sep 19, 2021 •

edited

Loading