Update LLVM to 21.1.3
Fixes https://github.com/rust-lang/rust/issues/146742.
After rust-lang/rust#146124, we need more space to run x86_64-gnu-distcheck if building LLVM from source. According to the building log, the space freed by `free-disk-space-linux.sh` is not entirely available.
```
You are running out of disk space.
The runner will stop working when the machine runs out of disk space.
Free space left: 98 MB
disk usage:
Filesystem Size Used Avail Use% Mounted on
/dev/root 72G 43G 29G 60% /
tmpfs 7.9G 84K 7.9G 1% /dev/shm
tmpfs 3.2G 1.2M 3.2G 1% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
/dev/sda16 881M 60M 760M 8% /boot
/dev/sda15 105M 6.2M 99M 6% /boot/efi
/dev/sdb1 74G 28K 70G 1% /mnt
tmpfs 1.6G 12K 1.6G 1% /run/user/1001
```
Most new API has an associated ACP that is useful to reference, but it
doesn't appear anywhere on the template for new tracking issues. Update
this template to include a link to the ACP.
rustdoc has its own issue template now, mention that.
swap the order of the last two sentances so it reads more like
a typical if/else chain (base case listed last).
adjust some labels and descriptions
Free disk space on Windows 2025 runners
I've managed to reduce the time deletion takes by:
- Using powershell, which is generally faster for filesystem operations than msys2
- Performing deletions concurrently then waiting for them all to complete
It still takes 2-10 mins but that's not too bad.
Unfortunately, the separate spellcheck GHA workflow does not really work
with homu, if we would like to enforce the invariant that PR CI is a
subset of Full CI (modulo carve outs).
This is not prejudice against a reland of a `typos`-based spellcheck, it
just probably has to go through the "usual" CI flow with bootstrap, so
that it can work with homu.
Add an aarch64-msvc build running on ARM64 Windows
Resurrecting rust-lang/rust#126341
Per <https://github.com/rust-lang/rfcs/pull/3817> we intend to promote `aarch64-pc-windows-msvc` to Tier 1. As part of that work, we are adding a pre-merge CI job to validate that changes do not break this target.
Additionally, for consistency, the `dist-aarch64-msvc` job will also be run on Arm64 Windows runners.
r? ``@Kobzol``
try-job: `*aarch64-msvc*`
Assign dependency bump PRs to me
These PRs sometimes get lost as GH reduces their visibility, so I wanted to get an assignment so I can help these PRs land
setup typos check in CI
This allows to check typos in CI, currently for compiler only (to reduce commit size with fixes). With current setup, exclude list is quite short, so it worth trying?
Also includes commits with actual typo fixes.
MCP: https://github.com/rust-lang/compiler-team/issues/817
typos check currently turned for:
* ./compiler
* ./library
* ./src/bootstrap
* ./src/librustdoc
After merging, PRs which enables checks for other crates (tools) can be implemented too.
Found typos will **not break** other jobs immediately: (tests, building compiler for perf run). Job will be marked as red on completion in ~ 20 secs, so you will not forget to fix it whenever you want, before merging pr.
Check typos: `python x.py test tidy --extra-checks=spellcheck`
Apply typo fixes: `python x.py test tidy --extra-checks=spellcheck:fix` (in case if there only 1 suggestion of each typo)
Current fail in this pr is expected and shows how typo errors emitted. Commit with error will be removed after r+.
That branch is essentially the same as the `try` branch, it also needs S3 permissions.
Long term, we should move rollup unrolling from rustc-perf to bors, so that we can have only a single try branch.
Inspired by some of the communication issues around the stabilization of
`let`-chains, give more fine-grained information about the status of
updating style for any new syntax.
This does not change the process or blockers in any way; it only
*documents* the current state in the tracking issue. For instance, in
the case of `let`-chains, we would have checked the boxes for "Style
team decision" and "(non-blocking) Formatting has been implemented", and
not checked the box for the style guide. That would have then provided
better supporting information for any decisions.
Update library tracking issue template to set S-tracking-unimplemented
This will help people notice the `S-tracking-*` labels, and if the
tracking issue *is* implemented, they can change the label.
Discussed in a `@rust-lang/libs-api` meeting.
r? `@Amanieu`
Jakub Beránek