Bring back i686-pc-windows-gnullvm target
rust-lang/rust#148751 inadvertently removed i686-pc-windows-gnullvm std build when migrating to native CI runners. Since this change was not agreed upon, we should bring back prebuilt std builds for that target.
There are a few runners that could do it: dist-aarch64-llvm-mingw, dist-x86_64-llvm-mingw, dist-various-1 and dist-various-2.
dist-x86_64-llvm-mingw already takes slightly over 2 hours, so the faster dist-aarch64-llvm-mingw is a better choice.
We can also use dist-various-x job, they don't have llvm-mingw toolchain, but it's trivial to install one.
Remove explicit install of `eslint` inside of `tidy`'s Dockerfile
`tidy` will already install it (when needed) due to it being in `package.json`
With this change, we don't have the version of `eslint` specific in two different places :)
(this was added in rust-lang/rust#141705 , before `tidy` gained the ability to run `npm install`, and is not needed anymore)
Implement the MCP 932: Promote riscv64a23-unknown-linux-gnu to Tier 2
Implement the [MCP 932](https://github.com/rust-lang/compiler-team/issues/932): Promote riscv64a23-unknown-linux-gnu to Tier 2 without host tools.
Closesrust-lang/rust#148353.
Changes:
- Update target tier from 3 to 2 in target specification
- Update platform documentation
- Add CI/CD support for automatic building and distribution via rustup
r? jieyouxu
cc `@davidtwco` `@Noratrieb`
Update memchr to 2.7.6
memchr 2.7.6 contains a bugfix for aarch64_be.
Note: I'm not sure about how dependency updates are managed in rust.git. If something should go through another branch or will happen automatically, please let me know.
Changes:
- Update target tier from 3 to 2 in target specification
- Update platform documentation
- Add CI/CD support for automatic building and distribution via rustup
Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#144194 (Provide additional context to errors involving const traits)
- rust-lang/rust#148232 (ci: add runners for vanilla LLVM 21)
- rust-lang/rust#148240 (rustc_codegen: fix musttail returns for cast/indirect ABIs)
- rust-lang/rust#148247 (Remove a special case and move another one out of reachable_non_generics)
- rust-lang/rust#148370 (Point at inner item when it uses generic type param from outer item or `Self`)
r? `@ghost`
`@rustbot` modify labels: rollup
ci: add runners for vanilla LLVM 21
Ubuntu 25.10 has `llvm-21` packages that we can test with.
The `Dockerfile` is otherwise the same as the `llvm-20` runners.
The LoongArch C/C++ cross toolchain defaults to the `normal` code model, which
can cause relocation overflows when linking LLVM after upgrading to verion 22.
This change uses the `medium`code model for `loongarch64-linux-gnu` and
`loongarch64-linux-musl` builds to avoid these linking errors.
Add tidy to the target of ./x check
## Context
Discussion: https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/tidy.20isn't.20in.20.2E.2Fx.20check/with/544323712
Currently `tidy` (src/tools/tidy) is not included in the list of `./x check`. It means that rust-analyzer doesn't work for codes in the directory if you use `./x check` as the analyzer on your IDE.
## Change
This PR adds src/tools/tidy into the target of `./x check`. It enables rust-analyzer highlight errors/warns on all codes in the directory.
Note that since tidy is implicitly checked by `./x test tidy`, this new check is off by default.
Not all ARMv7-A CPUs have a double-precision FPU. So adjust the CFLAGS
from `+vfpv3` (which assumes 32 double-precision registers) to `+fp`
(which only assumes 16 double-precision registers).
This commit adds src/tools/tidy into `./x check`. It enables rust-analyzer hightlights errors/warns on all codes in src/tools/tidy.
Since tidy is implicitly checked by `./x test tidy`, this new check is off by default.
Initialize llvm submodule if not already the case to run citool
While working on https://github.com/rust-lang/rust/pull/146414, I ran the following command (to run CI docker locally):
```
cargo run --manifest-path src/ci/citool/Cargo.toml run-local --type pr x86_64-gnu-gcc
```
However, since I didn't have `src/llvm` submodule initialized, it failed. Apparently it's a common issue for people using this tool so this PR removes this small inconvenience.
r? ``@Kobzol``
bors