Point to a move-related span when pointing to closure upvars #75933
Conversation
Fixes rust-lang#75904 When emitting move/borrow errors, we may point into a closure to indicate why an upvar is used in the closure. However, we use the 'upvar span', which is just an arbitrary usage of the upvar. If the upvar is used in multiple places (e.g. a borrow and a move), we may end up pointing to the borrow. If the overall error is a move error, this can be confusing. This PR tracks the span that caused an upvar to become captured by-value instead of by-ref (assuming that it's not a `move` closure). We use this span instead of the 'upvar' span when we need to point to an upvar usage during borrow checking.
|
r? @oli-obk (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
Have you considered changing the site where the |
|
@oli-obk: |
|
I think some upvar-related queries are in the process of being refactored to support disjoint fields capture (see #53488), which might make it easier to change the computation of |
|
oh, yea that makes sense. Can you open an issue about doing this change so we don't forget about it? @bors r+ |
|
📌 Commit b5b8b93 has been approved by |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions, checks-azure |
Fixes #75904
When emitting move/borrow errors, we may point into a closure to
indicate why an upvar is used in the closure. However, we use the
'upvar span', which is just an arbitrary usage of the upvar. If the
upvar is used in multiple places (e.g. a borrow and a move), we may end
up pointing to the borrow. If the overall error is a move error, this
can be confusing.
This PR tracks the span that caused an upvar to become captured by-value
instead of by-ref (assuming that it's not a
moveclosure). We use thisspan instead of the 'upvar' span when we need to point to an upvar usage
during borrow checking.