Rollup of 10 pull requests #73367
Rollup of 10 pull requests #73367
Conversation
Fixes rust-lang#69446 When we encounter a region error involving an `FnMut` closure, we display a specialized error message. However, we currently do not tell the user which upvar was captured. This makes it difficult to determine the cause of the error, especially when the closure is large. This commit records marks constraints involving closure upvars with `ConstraintCategory::ClosureUpvar`. When we decide to 'blame' a `ConstraintCategory::Return`, we additionall store the captured upvar if we found a `ConstraintCategory::ClosureUpvar` in the path. When generating an error message, we point to relevant spans if we have closure upvar information available. We further customize the message if an `async` closure is being returned, to make it clear that the captured variable is being returned indirectly.
Also, implement this query for the local crate, not just foreign crates.
It was applied to a `use` item, not to the module
This commit adds a `Closure` variant to `NonStructuralMatchTy` in `structural_match`, fixing an ICE which can occur when `impl_trait_in_bindings` is used with constants. Signed-off-by: David Wood <[email protected]>
The existing error documentation did not show how to use a child module's functions if the types used in those functions are private. These are some other places this problem has popped up that did not present a solution (these are from before the solution existed, 2016-2017. The solution was released in the Rust 2018 edition. However these were the places I was pointed to when I encountered the problem myself): rust-lang#30905 https://stackoverflow.com/questions/39334430/how-to-reference-private-types-from-public-functions-in-private-modules/62374958#62374958
…p-elab, r=oli-obk Check for live drops in constants after drop elaboration Resolves rust-lang#66753. This PR splits the MIR "optimization" pass series in two and introduces a query–`mir_drops_elaborated_and_const_checked`–that holds the result of the `post_borrowck_cleanup` analyses and checks for live drops. This query is invoked in `rustc_interface` for all items requiring const-checking, which means we now do `post_borrowck_cleanup` for items even if they are unused in the crate. As a result, we are now more precise about when drops are live. This is because drop elaboration can e.g. eliminate drops of a local when all its fields are moved from. This does not mean we are doing value-based analysis on move paths, however; Storing a `Some(CustomDropImpl)` into a field of a local will still set the qualifs for that entire local. r? @oli-obk
… r=nikomatsakis
Explain move errors that occur due to method calls involving `self`
When calling a method that takes `self` (e.g. `vec.into_iter()`), the method receiver is moved out of. If the method receiver is used again, a move error will be emitted::
```rust
fn main() {
let a = vec![true];
a.into_iter();
a;
}
```
emits
```
error[E0382]: use of moved value: `a`
--> src/main.rs:4:5
|
2 | let a = vec![true];
| - move occurs because `a` has type `std::vec::Vec<bool>`, which does not implement the `Copy` trait
3 | a.into_iter();
| - value moved here
4 | a;
| ^ value used here after move
```
However, the error message doesn't make it clear that the move is caused by the call to `into_iter`.
This PR adds additional messages to move errors when the move is caused by using a value as the receiver of a `self` method::
```
error[E0382]: use of moved value: `a`
--> vec.rs:4:5
|
2 | let a = vec![true];
| - move occurs because `a` has type `std::vec::Vec<bool>`, which does not implement the `Copy` trait
3 | a.into_iter();
| ------------- value moved due to this method call
4 | a;
| ^ value used here after move
|
note: this function takes `self`, which moves the receiver
--> /home/aaron/repos/rust/src/libcore/iter/traits/collect.rs:239:5
|
239 | fn into_iter(self) -> Self::IntoIter;
```
TODO:
- [x] Add special handling for `FnOnce/FnMut/Fn` - we probably don't want to point at the unstable trait methods
- [x] Consider adding additional context for operations (e.g. `Shr::shr`) when the call was generated using the operator syntax (e.g. `a >> b`)
- [x] Consider pointing to the method parent (impl or trait block) in addition to the method itself.
…rent-impl, r=estebank Fix trait alias inherent impl resolution Fixes rust-lang#60021 and fixes rust-lang#72415. Obviously, the fix was very easy, but getting started with the testing and debugging rust compiler was an interesting experience. Now I can cross it off my bucket list!
Stabilize vec::Drain::as_slice and add `AsRef<[T]> for Drain<'_, T>`. Tracking issue: rust-lang#58957. Does not stabilize `slice::IterMut::as_slice` yet. cc @cuviper This PR proposes stabilizing just the `vec::Drain::as_slice` part of that tracking issue. My ultimate goal here: being able to use `for<T, I: Iterator<Item=T> + AsRef<[T]>> I` to refer to `vec::IntoIter`, `vec::Drain`, and eventually `array::IntoIter`, as an approximation of the set of by-value iterators that can be "previewed" as by-ref iterators. (Actually expressing that as a trait requires GAT.)
…n, r=nikomatsakis Display information about captured variable in `FnMut` error Fixes rust-lang#69446 When we encounter a region error involving an `FnMut` closure, we display a specialized error message. However, we currently do not tell the user which upvar was captured. This makes it difficult to determine the cause of the error, especially when the closure is large. This commit records marks constraints involving closure upvars with `ConstraintCategory::ClosureUpvar`. When we decide to 'blame' a `ConstraintCategory::Return`, we additionall store the captured upvar if we found a `ConstraintCategory::ClosureUpvar` in the path. When generating an error message, we point to relevant spans if we have closure upvar information available. We further customize the message if an `async` closure is being returned, to make it clear that the captured variable is being returned indirectly.
Group `Pattern::strip_*` method together
_match.rs: fix module doc comment It was applied to a `use` item, not to the module
Fix iterator copied() documentation example code The documentation for copied() gives example code with variable v_cloned instead of v_copied. This seems like a copy/paste error from cloned() and it would be clearer to use v_copied.
Update E0446.md The existing error documentation did not show how to use a child module's functions if the types used in those functions are private. These are some other places this problem has popped up that did not present a solution (these are from before the solution existed, 2016-2017. The solution was released in the Rust 2018 edition. However these were the places I was pointed to when I encountered the problem myself): rust-lang#30905 https://stackoverflow.com/questions/39334430/how-to-reference-private-types-from-public-functions-in-private-modules/62374958#62374958
…l-match-ty-closures, r=varkor structural_match: non-structural-match ty closures Fixes rust-lang#73003. This PR adds a `Closure` variant to `NonStructuralMatchTy` in `structural_match`, fixing an ICE which can occur when `impl_trait_in_bindings` is used with constants.
|
📌 Commit bca9e90 has been approved by |
bors
added
the
S-waiting-on-bors
|
☀️ Test successful - checks-azure |
|
One or more PRs in this rollup caused a perf regression of up to 3.5%. @ecstatic-morse, @Aaron1011, @matthew-mcallister, @CAD97, @lzutao, @jonas-schievink, @schteve, @gnodarse, @davidtwco: any idea which PR(s) may have been the cause? |
|
@ecstatic-morse: #71824 would be my guess just by looking at the PR names, but I could easily be wrong about that. @RalfJung: #71824 had 8 commits, modified 16 files, and was (to my eye) non-trivial. What's the criteria for including a PR in a rollup? That feels to me like a PR that would have been better to land by itself. |
|
Because I marked it rollup=always. It only affects const items and only when a feature gate is enabled. It does add an intermediate MIR query that gets stolen from, but I'd be surprised if that was the culprit. |
|
The largest regressions are in the unchanged incremental benchmarks, and mostly in HIR lowering. I suspect one of the diagnostics improvements PRs made a frequently copied data structure larger. |
|
@Aaron1011: what do you think? |
|
The regression appears to be in |
It's a <1k line diff, so I would have considered rolling it up even without @ecstatic-morse's annotation. We have a huge queue so aggressively rolling up is our only option to keep PRs landing faster than they are approved. We can maybe land 2-3 PRs by themselves per day currently, everything else should be rollups of 10 PRs or more. |
What would be really useful for cases like this is being able to run rust-timer on a PR after it already landed... @rust-lang/infra is that something we can do? |
|
@nnethercote, #72598 caused a 1.4% increase in instruction count for full builds of I don't think we need to revert PRs that cause small regressions in unchanged incremental benchmarks (which run quite fast) or in a single uncommon crate. These two PRs both added non-trivial functionality; they weren't just refactoring. That said, I wonder if @Aaron1011 has any ideas to speed these PRs up? |
Successful merges:
self#72389 (Explain move errors that occur due to method calls involvingself)FnMuterror #72598 (Display information about captured variable inFnMuterror)Pattern::strip_*method together #73336 (GroupPattern::strip_*method together)Failed merges:
r? @ghost