-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 3 pull requests #124386
Rollup of 3 pull requests #124386
Conversation
``` error[E0499]: cannot borrow `foo` as mutable more than once at a time --> $DIR/suggest-split-at-mut.rs:13:18 | LL | let a = &mut foo[..2]; | --- first mutable borrow occurs here LL | let b = &mut foo[2..]; | ^^^ second mutable borrow occurs here LL | a[0] = 5; | ---- first borrow later used here | = help: use `.split_at_mut(position)` or similar method to obtain two mutable non-overlapping sub-slices ``` Address most of rust-lang#58792. For follow up work, we should emit a structured suggestion for cases where we can identify the exact `let (a, b) = foo.split_at_mut(2);` call that is needed.
Emit suggestion when encountering ```rust let a = &mut foo[0]; let b = &foo[1]; a.use_mut(); ```
Detect borrow error involving sub-slices and suggest `split_at_mut` ``` error[E0499]: cannot borrow `foo` as mutable more than once at a time --> $DIR/suggest-split-at-mut.rs:13:18 | LL | let a = &mut foo[..2]; | --- first mutable borrow occurs here LL | let b = &mut foo[2..]; | ^^^ second mutable borrow occurs here LL | a[0] = 5; | ---- first borrow later used here | = help: use `.split_at_mut(position)` or similar method to obtain two mutable non-overlapping sub-slices ``` Address most of rust-lang#58792. For follow up work, we should emit a structured suggestion for cases where we can identify the exact `let (a, b) = foo.split_at_mut(2);` call that is needed.
… r=lcnr Don't ICE when `codegen_select_candidate` returns ambiguity in new solver Because we merge identical candidates, we may have >1 impl candidate to in `codegen_select_error` but *not* have a trait error. r? lcnr
…strieb `Range` iteration specialization: remove trivial bounds These bounds on impl items are trivially true and never checked by a caller. They end up shadowing the actual impls, currently preventing normalization in the new solver. While we may have to fix the underlying issue in the new solver at some point, for now this is an easy way to get us closer to compiling core with `-Znext-solver`. r? `@Nilstrieb`
@bors r+ rollup=never p=3 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: 38dd569150 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (3a36386): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 671.322s -> 671.645s (0.05%) |
Successful merges:
split_at_mut
#124313 (Detect borrow error involving sub-slices and suggestsplit_at_mut
)codegen_select_candidate
returns ambiguity in new solver #124374 (Don't ICE whencodegen_select_candidate
returns ambiguity in new solver)Range
iteration specialization: remove trivial bounds #124380 (Range
iteration specialization: remove trivial bounds)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup