rust/tests/ui/pattern, branch 1.78.0

Rollup merge of #122254 - estebank:issue-48677, r=oli-obk

2024-03-15T20:51:56+00:00

Detect calls to .clone() on T: !Clone types on borrowck errors When encountering a lifetime error on a type that *holds* a type that doesn't implement `Clone`, explore the item's body for potential calls to `.clone()` that are only cloning the reference `&T` instead of `T` because `T: !Clone`. If we find this, suggest `T: Clone`. ``` error[E0502]: cannot borrow `*list` as mutable because it is also borrowed as immutable --> $DIR/clone-on-ref.rs:7:5 | LL | for v in list.iter() { | ---- immutable borrow occurs here LL | cloned_items.push(v.clone()) | ------- this call doesn't do anything, the result is still `&T` because `T` doesn't implement `Clone` LL | } LL | list.push(T::default()); | ^^^^^^^^^^^^^^^^^^^^^^^ mutable borrow occurs here LL | LL | drop(cloned_items); | ------------ immutable borrow later used here | help: consider further restricting this bound | LL | fn foo(list: &mut Vec) { | +++++++ ``` ``` error[E0505]: cannot move out of `x` because it is borrowed --> $DIR/clone-on-ref.rs:23:10 | LL | fn qux(x: A) { | - binding `x` declared here LL | let a = &x; | -- borrow of `x` occurs here LL | let b = a.clone(); | ------- this call doesn't do anything, the result is still `&A` because `A` doesn't implement `Clone` LL | drop(x); | ^ move out of `x` occurs here LL | LL | println!("{b:?}"); | ----- borrow later used here | help: consider annotating `A` with `#[derive(Clone)]` | LL + #[derive(Clone)] LL | struct A; | ``` Fix #48677.

Tweak wording

2024-03-13T23:05:17+00:00

Remove `MaybeInfiniteInt::JustAfterMax`

2024-03-13T13:17:11+00:00

It was inherited from before half-open ranges, but it doesn't pull its weight anymore. We lose a tiny bit of diagnostic precision.

Rollup merge of #121908 - Nadrieril:dynamic-variant-collection, r=matthewjasper

2024-03-13T05:41:21+00:00

match lowering: don't collect test alternatives ahead of time I'm very happy with this one. Before this, when sorting candidates into the possible test branches, we manually computed `usize` indices to determine in which branch each candidate goes. To make this work we had a first pass that collected the possible alternatives we'd have to deal with, and a second pass that actually sorts the candidates. In this PR, I replace `usize` indices with a dedicated enum. This makes `sort_candidates` easier to follow, and we don't need the first pass anymore. r? ``@matthewjasper``

Lint small gaps between ranges

2024-03-09T00:14:22+00:00

Allow lint where we don't care

2024-03-09T00:13:42+00:00

Rollup merge of #121917 - GuillaumeGomez:pattern-complexity_limit.rs, r=Nadrieril

2024-03-03T13:07:43+00:00

Add new `pattern_complexity` attribute to add possibility to limit and check recursion in pattern matching Needed for https://github.com/rust-lang/rust-analyzer/issues/9528. This PR adds a new attribute only available when running rust testsuite called `pattern_complexity` which allows to set the maximum recursion for the pattern matching. It is quite useful to ensure the complexity doesn't grow, like in `tests/ui/pattern/usefulness/issue-118437-exponential-time-on-diagonal-match.rs`. r? `@Nadrieril`

Add and update tests to use `pattern_complexity`

2024-03-03T12:10:15+00:00

Rollup merge of #121716 - Nadrieril:simple-binding-order, r=matthewjasper

2024-03-02T19:13:23+00:00

match lowering: Lower bindings in a predictable order After the recent refactorings, we can now lower bindings in a truly predictable order. The order in https://github.com/rust-lang/rust/pull/120214 was an improvement but not very clear. With this PR, we lower bindings from left to right, with the special case that `x @ pat` is traversed as `pat @ x` (i.e. `x` is lowered after any bindings in `pat`). This description only applies in the absence of or-patterns. Or-patterns make everything complicated, because the binding place depends on the subpattern. Until I have a better idea I leave them to be handled in whatever weird order arises from today's code. r? `@matthewjasper`

Fix a subtle regression

2024-03-02T17:38:37+00:00

Before, the SwitchInt cases were computed in two passes: if the first pass accepted e.g. 0..=5 and then 1, the second pass would not accept 0..=5 anymore because 1 would be listed in the SwitchInt options. Now there's a single pass, so if we sort 0..=5 we must take care to not sort a subsequent 1.