A few cleanups for rustc_data_structures
- remove a redundant `clone()`
- make some calls to `.iter()` implicit
- collapse/simplify a few operations
- remove some explicit `return`s
- make `SnapshotMap::{commit, rollback_to}` take references
- remove unnecessary struct field names
- change `transmute()`s in `IdxSet::{from_slice, from_slice_mut}` to casts
- remove some unnecessary lifetime annotations
- split 2 long literals
Consider changing assert! to debug_assert! when it calls visit_with
The perf run from #52956 revealed that there were 3 benchmarks that benefited most from changing `assert!`s to `debug_assert!`s:
- issue #46449: avg -4.7% for -check
- deeply-nested (AKA #38528): avg -3.4% for -check
- regression #31157: avg -3.2% for -check
I analyzed their fixing PRs and decided to look for potentially heavy assertions in the files they modified. I noticed that all of the non-trivial ones contained indirect calls to `visit_with()`.
It might be a good idea to consider changing `assert!` to `debug_assert!` in those places in order to get the performance wins shown by the benchmarks.
Don't collect() when size_hint is useless
This adjusts PRs #52738 and #52697 by falling back to calculating capacity and extending or pushing in a loop where `collect()` can't be trusted to calculate the right capacity.
It is a performance win.
Update compiler test documentation
Update the compiler test documentation to document ignore-gdb-version
and min-system-llvm-version; and expand the min-gdb-version,
min-lldb-version, and min-llvm-version documentation a little.
The error and check for this already existed, but the parser didn't try to parse trait method arguments as patterns, so the error was never emitted. This surfaces the error, so we get better errors than simple parse errors.
There are a few places where we mention the replacement character in the
docs, and it could be helpful for users to utilize the constant which is
available in the standard library, so let’s link to it!
optimize redundant borrows and escaping paths in NLL
This builds on https://github.com/rust-lang/rust/pull/53168 and adds a commit that addresses https://github.com/rust-lang/rust/issues/53176 -- or at least I think it does. I marked this as WIP because I want to see the test results (and measure the performance). I also want to double check we're not adding in any unsoundness here.
As explained by eddyb in #53221, "An &ArchiveChild doesn't point into the archive itself, it points to an owned object that itself points to the archive, and LLVMRustArchiveMemberNew copies the ArchiveChild (whereas the current signature suggests it keeps the &ArchiveChild)."
Cleanup to librustc::session and related code
No functional changes, just some cleanup.
This also creates the `rustc_fs_util` crate, but I can remove that change if desired. It felt a little odd to force crates to depend on librustc for some fs utilities; and also seemed good to generally keep the size of librustc lower (for compile times); fs_util will compile in parallel with essentially the first crate since it has no dependencies beyond std.
Add help message for missing `IndexMut` impl
Code:
```rust
let mut map = HashMap::new();
map.insert("peter", 23);
map["peter"] = 27;
```
Before:
```
error[E0594]: cannot assign to immutable indexed content
--> src/main.rs:7:5
|
7 | map["peter"] = 27;
| ^^^^^^^^^^^^^^^^^ cannot borrow as mutable
```
With this change (just the `help` was added):
```
error[E0594]: cannot assign to immutable indexed content
--> index-error.rs:7:5
|
7 | map["peter"] = 27;
| ^^^^^^^^^^^^^^^^^ cannot borrow as mutable
|
= help: trait `IndexMut` is required to modify indexed content, but it is not implemented for std::collections::HashMap<&str, i32>
```
---
Yesterday I did some pair programming with a Rust-beginner. We created a type and implemented `Index` for it. Trying to modify the value returned by the index operation returns in a rather vague error that was not very clear for the Rust beginner. So I tried to improve the situation.
## Notes/questions for reviewers:
- Is the formulation OK like that? I'm fine with changing it.
- Can we be absolutely sure that `IndexMut` is actually not implemented in the case my `help` message is added? I'm fairly sure myself, but there could be some cases I didn't think of. Also, I don't know the compiler very well, so I don't know what exactly certain enum variants are used for.
- It would be nice to test if `IndexMut` is in fact not implemented for the type, but I couldn't figure out how to check that. If you think that additional check would be beneficial, could you tell me how to check if a trait is implemented?
- Do you think I should change the error message instead of only adding an additional help message?
