Add ConstraintCategory::Usage for handling aggregate construction#88708
Add ConstraintCategory::Usage for handling aggregate construction#88708bors merged 1 commit intorust-lang:masterfrom
ConstraintCategory::Usage for handling aggregate construction#88708Conversation
|
r? @oli-obk (rust-highfive has picked a reviewer for you, use r? to override) |
|
☔ The latest upstream changes (presumably #80522) made this pull request unmergeable. Please resolve the merge conflicts. |
9e4772b to
3feddf7
Compare
|
@bors r+ rollup |
|
📌 Commit 3feddf7 has been approved by |
Add `ConstraintCategory::Usage` for handling aggregate construction
In some cases, we emit borrowcheck diagnostics pointing
at a particular field expression in a struct expression
(e.g. `MyStruct { field: my_expr }`). However, this
behavior currently relies on us choosing the
`ConstraintCategory::Boring` with the 'correct' span.
When adding additional variants to `ConstraintCategory`,
(or changing existing usages away from `ConstraintCategory::Boring`),
the current behavior can easily get broken, since a non-boring
constraint will get chosen over a boring one.
To make the diagnostic output less fragile, this commit
adds a `ConstraintCategory::Usage` variant. We use this variant
for the temporary assignments created for each field of
an aggregate we are constructing.
Using this new variant, we can emit a message mentioning
"this usage", emphasizing the fact that the error message
is related to the specific use site (in the struct expression).
This is preparation for additional work on improving NLL error messages
(see rust-lang#57374)
Add `ConstraintCategory::Usage` for handling aggregate construction
In some cases, we emit borrowcheck diagnostics pointing
at a particular field expression in a struct expression
(e.g. `MyStruct { field: my_expr }`). However, this
behavior currently relies on us choosing the
`ConstraintCategory::Boring` with the 'correct' span.
When adding additional variants to `ConstraintCategory`,
(or changing existing usages away from `ConstraintCategory::Boring`),
the current behavior can easily get broken, since a non-boring
constraint will get chosen over a boring one.
To make the diagnostic output less fragile, this commit
adds a `ConstraintCategory::Usage` variant. We use this variant
for the temporary assignments created for each field of
an aggregate we are constructing.
Using this new variant, we can emit a message mentioning
"this usage", emphasizing the fact that the error message
is related to the specific use site (in the struct expression).
This is preparation for additional work on improving NLL error messages
(see rust-lang#57374)
3feddf7 to
e2877e3
Compare
|
The tests are passing locally - this must have conflicted with one of the other PRs in the rollup. @bors r=oli-obk |
|
📌 Commit e2877e3ab28eabaec7ea81f96a50e6ec6b6443b8 has been approved by |
|
It was an NLL test that failed btw |
In some cases, we emit borrowcheck diagnostics pointing
at a particular field expression in a struct expression
(e.g. `MyStruct { field: my_expr }`). However, this
behavior currently relies on us choosing the
`ConstraintCategory::Boring` with the 'correct' span.
When adding additional variants to `ConstraintCategory`,
(or changing existing usages away from `ConstraintCategory::Boring`),
the current behavior can easily get broken, since a non-boring
constraint will get chosen over a boring one.
To make the diagnostic output less fragile, this commit
adds a `ConstraintCategory::Usage` variant. We use this variant
for the temporary assignments created for each field of
an aggregate we are constructing.
Using this new variant, we can emit a message mentioning
"this usage", emphasizing the fact that the error message
is related to the specific use site (in the struct expression).
This is preparation for additional work on improving NLL error messages
(see rust-lang#57374)
e2877e3 to
a41a13f
Compare
|
📌 Commit a41a13f has been approved by |
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (0c0826c): 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 |
In some cases, we emit borrowcheck diagnostics pointing
at a particular field expression in a struct expression
(e.g.
MyStruct { field: my_expr }). However, thisbehavior currently relies on us choosing the
ConstraintCategory::Boringwith the 'correct' span.When adding additional variants to
ConstraintCategory,(or changing existing usages away from
ConstraintCategory::Boring),the current behavior can easily get broken, since a non-boring
constraint will get chosen over a boring one.
To make the diagnostic output less fragile, this commit
adds a
ConstraintCategory::Usagevariant. We use this variantfor the temporary assignments created for each field of
an aggregate we are constructing.
Using this new variant, we can emit a message mentioning
"this usage", emphasizing the fact that the error message
is related to the specific use site (in the struct expression).
This is preparation for additional work on improving NLL error messages
(see #57374)