Based on lessons learned from 2024. There's probably still more details
to say here since it was a ton of work. These are the major points that
I remember.
It was observed that some people were missing the `edition20xx` rustdoc
attribute. Although this probably won't solve that problem, I'd still
like to highlight it as something to be aware of.
Correctly display stdout and stderr in case a doctest is failing
Fixes https://github.com/rust-lang/rust/issues/140289.
Since the doctest is actually running itself, we need to handle the output directly inside it.
cc `@fmease`
r? `@notriddle`
check types of const param defaults
fixes#139643 by checking that the type of a const parameter default matches the type of the parameter as long as both types are fully concrete
r? `@BoxyUwU`
[compiletest] Parallelize test discovery
Certain filesystems are slow to service individual read requests, but can service many in parallel. This change brings down the time to run a single cached test on one of those filesystems from 40s to about 8s.
Allow out of order dep graph node encoding
This allows out of order dep graph node encoding by also encoding the index instead of using the file node order as the index.
`MemEncoder` is also brought back to life and used for encoding.
Both of these are done to enable thread-local encoding of dep graph nodes.
This is based on https://github.com/rust-lang/rust/pull/139636.
Revert compiletest new-executor, to re-land without download-rustc
Revert <https://github.com/rust-lang/rust/pull/139998> because the original merge triggered download-rustc, which messes with test metrics and prevents us from properly comparing them before/after the change.
The plan is to re-land this PR as-is, combined with a trivial compiler change to avoid download-rustc and get proper test metrics for comparison.
This reverts commit be181dd75c83d72fcc95538e235768bc367b76b9, reversing changes made to 645d0ad2a4f145ae576e442ec5c73c0f8eed829b.
r? ghost
Remove comment about handling non-global where bounds with corresponding projection
This comment is no longer relevant since we only assemble rigid projections if no param-env candidates hold.
Also remove a stray comment from the old solver.
r? lcnr
minicore: Have `//@ add-core-stubs` also imply `-Cforce-unwind-tables=yes`
To preserve CFI directives in assembly tests, as `//@ add-core-stubs` already imply `-C panic=abort`.
This is a blocker for https://github.com/rust-lang/rust/pull/140037#issuecomment-2816665358.
cc ```@RalfJung```
r? ```@bjorn3```
mitigate MSVC alignment issue on x86-32
This implements mitigation for https://github.com/rust-lang/rust/issues/112480 by stopping to emit `align` attributes on loads and function arguments when building for a win32 MSVC target. MSVC is known to not properly align `u64` and similar types, and claiming to LLVM that everything is properly aligned increases the chance that this will cause problems.
Of course, the misalignment is still a bug, but we can't fix that bug, only MSVC can.
Also add an errata note to the platform support page warning users about this known problem.
try-job: `i686-msvc*`
make abi_unsupported_vector_types a hard error
Fixes https://github.com/rust-lang/rust/issues/116558 by completing the transition; see that issue for context. The lint was introduced with Rust 1.84 and this has been shown in cargo's future breakage reports since Rust 1.85, released 6 weeks ago, and so far we got 0 complaints by users. There's not even a backlink on the tracking issue. We did a [crater run](https://github.com/rust-lang/rust/pull/127731#issuecomment-2286736295) when the lint was originally added and found no breakage. So I don't think we need another crater run now, but I can do one if the team prefers that.
https://github.com/rust-lang/rust/issues/131800 is done, so for most current targets (in particular, all tier 1 and tier 2 targets) we have the information to implement this check (modulo the targets where we don't properly support SIMD vectors yet, see the sub-issues of https://github.com/rust-lang/rust/issues/116558). If a new target gets added in the future, it will default to reject all SIMD vector types until proper information is added, which is the default we want.
This will need approval by for `@rust-lang/lang.` Cc `@workingjubilee` `@veluca93`
try-job: test-various
try-job: armhf-gnu
try-job: dist-i586-gnu-i586-i686-musl
Refactor git change detection in bootstrap
While working on https://github.com/rust-lang/rust/pull/138395, I finally found the courage to delve into the insides of git path change detection in bootstrap, which is used (amongst other things) to detect if we should rebuilt od download `[llvm|rustc|gcc]`. I found it a bit hard to understand, and given that this code was historically quite fragile, I thought that it would be better to rebuild it from scratch.
The previous approach had a bunch of limitations:
- It separated the computation of "are there local changes?" and "what upstream SHA should we use?" even though these two things are intertwined.
- It used hacks to work around what happens on CI.
- It had special cases for CI scattered throughout the codebase, rather than centralized in one place.
- It wasn't documented enough and didn't have tests for the git behavior.
The current approach should hopefully resolve all of that. I implemented a single entrypoint called `check_path_modifications` (naming bikeshed pending, half of the time I spend on this PR was thinking about names, as it's quite tricky here..) that explicitly receives a mode of operation (in CI or outside CI), and accordingly figures out that upstream SHA that we should use for downloading artifacts and it also figures out if there are any local changes. Users of this function can then use this unified output to implement `download-ci-X` and other functionality. Notably, this change detection no longer uses `git merge-base`, which makes it easier to use and doesn't require setting up remotes.
I also added a bunch of integration tests that literally spawn a git repository on disk and then check that the function can deal with various situations (PR CI, auto/try CI, local builds).
After I built this inner layer, I used it for downloading GCC, LLVM and rustc. The latter two (and especially rustc) were using the `last_modified_commit` function before, but in all cases but one this function was actually only used to check if there are any local changes, which was IMO confusing. The LLVM handling would deserve a bit of refactoring, but that's a larger change that can be done as a follow-up.
I hope that the implementation is now clear and easy to understand, so that in combination with the tests we can have more confidence that it does what we want. I tried to include a lot of documentation in the code, so I won't be repeating the actual implementation details here, if there are any questions, I'll add the answers to the documentation too :)
The new approach explicitly supports three scenarios:
- Running on PR CI, where we have one upstream bors parent commit and one PR merge commit made by GitHub.
- Running on try/auto CI, where we have one upstream bors parent commit and one PR merge commit made by bors.
- Running locally, where we assume that we have at least one upstream bors parent commit in our git history.
I removed the handling of upstreams on CI, as I think that it shouldn't be needed and I considered it to be a hack. However, it's possible that there are other use-cases that I haven't considered, so I want to ask around if people have other situations than the three use-cases described above. If there are other such use-cases, I would like to include them in the new centralized implementation and add them to the git test suite, rather than going back to the old ways :)
In particular, the code before relied on `git merge-base`, but I don't see why we can't just lookup the most recent bors commit and assume that is a merge commit that is also upstream? I might be running into Chesterton's Fence here :)
CC `@pietroalbini` To make sure that this won't break downstream users of Rust's CI.
Best reviewed commit by commit.
Companion PRs:
- For testing beta: https://github.com/rust-lang/rust/pull/138597
r? `@onur-ozkan`
Fixes: https://github.com/rust-lang/rust/issues/101907
try-job: x86_64-gnu-aux
try-job: aarch64-gnu
try-job: dist-x86_64-apple
Add tests for two untested cases of placeholder relations
During work on #130227, I discovered several situations not covered by any previously existing UI test. This commit introudces tests to cover that.
r? lcnr
Remove `token::{Open,Close}Delim`
By replacing them with `{Open,Close}{Param,Brace,Bracket,Invisible}`.
PR #137902 made `ast::TokenKind` more like `lexer::TokenKind` by
replacing the compound `BinOp{,Eq}(BinOpToken)` variants with fieldless
variants `Plus`, `Minus`, `Star`, etc. This commit does a similar thing
with delimiters. It also makes `ast::TokenKind` more similar to
`parser::TokenType`.
This requires a few new methods:
- `TokenKind::is_{,open_,close_}delim()` replace various kinds of
pattern matches.
- `Delimiter::as_{open,close}_token_kind` are used to convert
`Delimiter` values to `TokenKind`.
Despite these additions, it's a net reduction in lines of code. This is
because e.g. `token::OpenParen` is so much shorter than
`token::OpenDelim(Delimiter::Parenthesis)` that many multi-line forms
reduce to single line forms. And many places where the number of lines
doesn't change are still easier to read, just because the names are
shorter, e.g.:
```
- } else if self.token != token::CloseDelim(Delimiter::Brace) {
+ } else if self.token != token::CloseBrace {
```
r? `@petrochenkov`
jsondocck: Require command is at start of line
In one place we use `///``@``` instead of `//``@`.`` The test-runner allowed it, but it probably shouldn't. Ran into by ``@lolbinarycat`` in https://github.com/rust-lang/rust/pull/132748#issuecomment-2816469322:
```
error: unknown disambiguator `?(`
##[error] --> /checkout/tests/rustdoc-json/fns/return_type_alias.rs:3:25
|
3 | ///@ set foo = "$.index[?(``@.name=='Foo')].id"``
| ^^
|
```
Maybe it's also worth erroring on this like we added in #137103
r? ``@GuillaumeGomez``
rustdoc-json: Improve test for auto-trait impls
The TODO is fixable now due-to #138763. While I was here I realized there's probably a a few more things we should also test.
r? ```@GuillaumeGomez```
Fix error when an intra doc link is trying to resolve an empty associated item
Fixes https://github.com/rust-lang/rust/issues/140026.
Assigning ```@nnethercote``` since they're the one who wrote the initial change.
I updated rustdoc code instead of compiler's because I think it makes more sense that the caller ensures on their side that the name they're looking for isn't empty.
r? ```@nnethercote```
Advent of `tests/ui` (misc cleanups and improvements) [4/N]
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of #133895.
### Review advice
- Best reviewed commit-by-commit.
- I can squash commits before merge, commits are separate to make it easier to review.
Clarify why SGX code specifies linkage/symbol names for certain statics
Specifying linkage/symbol name is solely to ensure a single instance between the `std` crate and its unit tests.
Also update the symbol names as items have moved around a bit. The actual name isn't that important, it just needs to be unique. But for debugging it can be useful for it to point to the right place.
Hermit: Unify `std::env::args` with Unix
The only differences between these implementations of `std::env::args` are that Unix uses relaxed ordering, but Hermit uses acquire/release, and Unix truncates `argv` at the first null pointer, but Hermit doesn't. Since Hermit aims for Unix compatibility, unify it with Unix.
The atomic orderings were established in https://github.com/rust-lang/rust/pull/74006 (cc `@euclio)` for Unix and https://github.com/rust-lang/rust/pull/100579 (cc `@joboet)` for Hermit and, before those, they used mutexes and non-atomic statics. I think the difference in orderings is simply from them being changed at different times. The commented explanation for using acquire/release for Hermit is “to broadcast writes by the OS”. I'm not experienced enough with atomics to accurately judge, but I think acquire/release is stronger than needed. Either way, they should match.
Truncating at the first null pointer seems desirable, though I don't know whether it is necessary in practice on Hermit.
cc `@mkroening` `@stlankes` for Hermit
Eric Huss
Tshepang Mbambo
The rustc-dev-guide Cronjob Bot
Yuki Okushi
bors
Matthias Krüger
Jieyou Xu
Manuel Drehwald
Chris Denton