Rollup of 10 pull requests
Successful merges:
- #135773 (Clarify WindowsMut (Lending)Iterator)
- #135807 (Implement phantom variance markers)
- #135876 (fix doc for std::sync::mpmc)
- #135988 (Add a workaround for parallel rustc crashing when there are delayed bugs)
- #136037 (Mark all NuttX targets as tier 3 target and support the standard library)
- #136064 (Add a suggestion to cast target_feature fn items to fn pointers.)
- #136082 (Incorporate `iter_nodes` into `graph::DirectedGraph`)
- #136112 (Clean up all dead files inside `tests/ui/`)
- #136114 (Use identifiers more in diagnostics code)
- #136118 (Change `collect_and_partition_mono_items` tuple return type to a struct)
r? `@ghost`
`@rustbot` modify labels: rollup
Change `collect_and_partition_mono_items` tuple return type to a struct
https://github.com/rust-lang/rust/pull/133429 will add a new field to this tuple, so it seems prudent to turn it into a struct first to avoid confusion about what the tuple elements mean.
Use identifiers more in diagnostics code
This should make the diagnostics code slightly more correct when rendering idents in mixed crate edition situations. Kinda a no-op, but a cleanup regardless.
r? oli-obk or reassign
Clean up all dead files inside `tests/ui/`
While rebasing #135860 I noticed that there are several dead `*.stderr` files inside `tests/ui/`.
When I checked thoroughly, I found 69 dead `*.$revision.stderr` files, 3 other dead `*.stderr` files and one dead `*.rs` file.
Prior to #134808, compiletest's `--bless` didn't remove dead `*.stderr` files when the set of revisions changed in any way (renamings, removals, additions, …) which explains their existence.
Regarding the dead `*.rs` file, that one was located inside an `auxiliary/` directory (together with a `*.stderr` file) despite not being meant to be an auxiliary file (it's not referenced by any `//@ aux-*`, it has an accompanying `*.stderr` file and it's obvious from looking at #111056 which added it). Ideally compiletest or tidy would forbid `*.std{out,err}` files inside `auxiliary/` dirs, that would've caught it. I moved it, updated it and turned it into a proper UI test.
---
How to reproduce:
1. Run `rm tests/ui/**/*.stderr`
2. Run `./x test tests/ui --bless` (or similar)
3. Manually / semi-automatically go through all tests that were ignored (likely due to your OS etc. not matching) and restore any stderr files that were overzealously removed
---
r? compiler
Incorporate `iter_nodes` into `graph::DirectedGraph`
This helper method iterates over all node IDs in the dense range `0..num_nodes`.
In practice, we have a lot of graph-algorithm code that already assumes that nodes are densely numbered, by using `num_nodes` to allocate per-node indexed data structures. So I don't think this is actually a substantial change to the de-facto semantics of `graph::DirectedGraph`.
---
Resolves a FIXME from #135481.
Add a workaround for parallel rustc crashing when there are delayed bugs
This doesn't fix the root cause of this crash, but at least stops it from happening for the time being.
Workaround for https://github.com/rust-lang/rust/issues/135870
Put the core unit tests in a separate coretests package
Having standard library tests in the same package as a standard library crate has bad side effects. It causes the test to have a dependency on a locally built standard library crate, while also indirectly depending on it through libtest. Currently this works out fine in the context of rust's build system as both copies are identical, but for example in cg_clif's tests I've found it basically impossible to compile both copies with the exact same compiler flags and thus the two copies would cause lang item conflicts.
This PR moves the tests of libcore to a separate package which doesn't depend on libcore, thus preventing the duplicate crates even when compiler flags don't exactly match between building the sysroot (for libtest) and building the test itself. The rest of the standard library crates do still have this issue however.
This needs more time to bake before we turn it on. Turning it on early risks people silencing the warning indefinitely, before we have the chance to make it less noisy.
Add some tracing to core bootstrap logic
Follow-up to #135391.
### Summary
Add some initial tracing logging to bootstrap, focused on the core logic (in this PR).
Also:
- Adjusted tracing-tree style to not use indent lines (I found that more distracting than helpful).
- Avoid glob-importing `tracing` items.
- Improve the rustc-dev-guide docs on bootstrap tracing.
### Example output
```bash
$ BOOTSTRAP_TRACING=bootstrap=TRACE ./x check src/bootstrap
```
r? bootstrap
compiler_fence: fix example
The old example was wrong, an acquire fence is required in the signal handler. To make the point more clear, I changed the "data" variable to use non-atomic accesses.
Fixes https://github.com/rust-lang/rust/issues/133014
Move `std::io::pipe` code into its own file
Also update the docs for the new location, create a section "Platform-specific behavior", don't hide required imports for code examples.
Uplift `clippy::double_neg` lint as `double_negations`
Warns about cases like this:
```rust
fn main() {
let x = 1;
let _b = --x; //~ WARN use of a double negation
}
```
The intent is to keep people from thinking that `--x` is a prefix decrement operator. `++x`, `x++` and `x--` are invalid expressions and already have a helpful diagnostic.
I didn't add a machine-applicable suggestion to the lint because it's not entirely clear what the programmer was trying to achieve with the `--x` operation. The code that triggers the lint should always be reviewed manually.
Closes#82987
- `check-pass` test for a MRE of #135020
- fail test for #135138
- switch to `TooGeneric` for checking CMSE fn signatures
- switch to `TooGeneric` for compute `SizeSkeleton` (for transmute)
- fix broken tests
Consistently use the highest bit of vector masks when converting to i1 vectors
This improves the codegen for vector `select`, `gather`, `scatter` and boolean reduction intrinsics and fixesrust-lang/portable-simd#316.
The current behavior of most mask operations during llvm codegen is to truncate the mask vector to <N x i1>, telling llvm to use the least significat bit. The exception is the `simd_bitmask` intrinsics, which already used the most signifiant bit.
Since sse/avx instructions are defined to use the most significant bit, truncating means that llvm has to insert a left shift to move the bit into the most significant position, before the mask can actually be used.
Similarly on aarch64, mask operations like blend work bit by bit, repeating the least significant bit across the whole lane involves shifting it into the sign position and then comparing against zero.
By shifting before truncating to <N x i1>, we tell llvm that we only consider the most significant bit, removing the need for additional shift instructions in the assembly.
This avoids a good deal of work, since each module child can now just be
compared via u32 comparison, rather than fetching the raw &str
(requiring locking and indexing into the interner) and then comparing
the two strings (also relatively expensive).
