Cleanup: delete `//@ pretty-expanded` directive
This PR removes the `//@ pretty-expanded` directive support in compiletest and removes its usage inside ui tests because it does not actually do anything, and its existence is itself misleading. This PR is split into two commits:
1. The first commit just drops `pretty-expanded` directive support in compiletest.
2. The second commit is created by `sd '//@ pretty-expanded.*\n' '' tests/ui/**/*.rs`[^1], reblessing, and slightly adjusting some leading whitespace in a few tests.
We can tell this is fully removed because compiletest doesn't complain about unknown directive when running the `ui` test suite.
cc #23616
### History
Originally, there was some effort to introduce more test coverage for `-Z unpretty=expanded` (in 2015 this was called `--pretty=expanded`). In [Make it an error to not declare used features #23598][pr-23598], there was a flip from `//@ no-pretty-expanded` (opt-out of `-Z
unpretty=expanded` test) to `//@ pretty-expanded` (opt-in to `-Z unpretty=expanded` test). This was needed because back then the dedicated `tests/pretty` ("pretty") test suite did not existed, and the pretty tests were grouped together under `run-pass` tests (I believe the `ui` test suite didn't exist back then either). Unfortunately, in this process the replacement `//@ pretty-expanded` directives contained a `FIXME #23616` linking to [There are very few tests for `-Z unpretty` expansion #23616][issue-23616]. But this was arguably backwards and somewhat misleading, as noted in [#23616](https://github.com/rust-lang/rust/issues/23616#issuecomment-484999901):
The attribute is off by default and things just work if you don't
test it, people have not been adding the `pretty-expanded`
annotation to new tests even if it would work.
Which basically renders this useless.
### Current status
As of Nov 2024, we have a dedicated `pretty` test suite, and some time over the years the split between `run-pass` into `ui` and `pretty` test suites caused all the `//@ pretty-expanded` in `ui` tests to do absolutely nothing: the compiletest logic for `pretty-expanded` only triggers in the *pretty* test suite, but none of the pretty tests use it. Oops.
Nobody remembers this, nobody uses this, it's misleading in ui tests. Let's get rid of this directive altogether.
[pr-23598]: https://github.com/rust-lang/rust/pull/23598
[issue-23616]: https://github.com/rust-lang/rust/issues/23616
### Follow-ups
- [x] Yeet this directive from rustc-dev-guide docs. https://github.com/rust-lang/rustc-dev-guide/pull/2147
[^1]: https://github.com/chmln/sd
r? compiler
Use ReadCache for archive reading in bootstrap
Address expensive archive reading in bootstrap. This fixes https://github.com/rust-lang/rust/issues/133268
Enable the `std` feature of `object` to use `ReadCache` instead of reading the entire archive file into memory to check for headers. This takes minimal extra time to compile compared to introducing other expensive dependencies to `bootstrap`.
r? jieyouxu
Refactor `where` predicates, and reserve for attributes support
Refactor `WherePredicate` to `WherePredicateKind`, and reserve for attributes support in `where` predicates.
This is a part of #115590 and is split from #132388.
r? petrochenkov
Foreword
========
Let us begin the journey to rediscover what the `//@ pretty-expanded`
directive does, brave traveller --
"My good friend, [..] when I wrote that passage, God and I knew what
it meant. It is possible that God knows it still; but as for me, I
have totally forgotten."
-- Johann Paul Friedrich Richter, 1826
We must retrace the steps of those before us, for history shall guide us
in the present and inform us of the future.
The Past
========
Originally there was some effort to introduce more test coverage for `-Z
unpretty=expanded` (in 2015 this was called `--pretty=expanded`). In
[Make it an error to not declare used features #23598][pr-23598], there
was a flip from `//@ no-pretty-expanded` (opt-out of `-Z
unpretty=expanded` test) to `//@ pretty-expanded` (opt-in to `-Z
unpretty=expanded` test). This was needed because back then the
dedicated `tests/pretty` ("pretty") test suite did not existed, and the
pretty tests were grouped together under `run-pass` tests (I believe
`ui` test suite didn't exist back then either). Unfortunately, in this
process the replacement `//@ pretty-expanded` directives contained a
`FIXME #23616` linking to [There are very few tests for `-Z unpretty`
expansion #23616][issue-23616]. But this was arguably backwards and
somewhat misleading, as noted in
<https://github.com/rust-lang/rust/issues/23616#issuecomment-484999901>:
The attribute is off by default and things just work if you don't
test it, people have not been adding the `pretty-expanded`
annotation to new tests even if it would work.
Which basically renders this useless.
The Present
===========
As of Nov 2024, we have a dedicated `pretty` test suite, and some time
over the years the split between `run-pass` into `ui` and `pretty` test
suites caused all of the `//@ pretty-expanded` in `ui` tests to do
absolutely nothing -- the compiletest logic for `pretty-expanded` only
triggered in the *pretty* test suite, but none of the pretty tests use
it. Oops.
The Future
==========
Nobody remembers this, nobody uses this, it's misleading in ui tests.
Let's get rid of this directive altogether.
[pr-23598]: https://github.com/rust-lang/rust/pull/23598
[issue-23616]: https://github.com/rust-lang/rust/issues/23616
Support input/output in vector registers of s390x inline assembly (under asm_experimental_reg feature)
This extends currently clobber-only vector registers (`vreg`) support to allow passing `#[repr(simd)]` types, floats (f32/f64/f128), and integers (i32/i64/i128) as input/output.
This is unstable and gated under new `#![feature(asm_experimental_reg)]` (tracking issue: https://github.com/rust-lang/rust/issues/133416). If the feature is not enabled, only clober is supported as before.
| Architecture | Register class | Target feature | Allowed types |
| ------------ | -------------- | -------------- | -------------- |
| s390x | `vreg` | `vector` | `i32`, `f32`, `i64`, `f64`, `i128`, `f128`, `i8x16`, `i16x8`, `i32x4`, `i64x2`, `f32x4`, `f64x2` |
This matches the list of types that are supported by the vector registers in LLVM:
https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td#L301-L313
In addition to `core::simd` types and floats listed above, custom `#[repr(simd)]` types of the same size and type are also allowed. All allowed types other than i32/f32/i64/f64/i128, and relevant target features are currently unstable.
Currently there is no SIMD type for s390x in `core::arch`, but this is tracked in https://github.com/rust-lang/rust/issues/130869.
cc https://github.com/rust-lang/rust/issues/130869 about vector facility support in s390x
cc https://github.com/rust-lang/rust/issues/125398 & https://github.com/rust-lang/rust/issues/116909 about f128 support in asm
`@rustbot` label +O-SystemZ +A-inline-assembly
Rollup of 6 pull requests
Successful merges:
- #132730 (std: allow after-main use of synchronization primitives)
- #133105 (only store valid proc macro item for doc link)
- #133260 (Constify the `Deref`/`DerefMut` traits, too)
- #133297 (Remove legacy bitcode for iOS)
- #133298 (Mention that std::fs::remove_dir_all fails on files)
- #133384 (add a test for target-feature-ABI warnings in closures and when calling extern fn)
r? `@ghost`
`@rustbot` modify labels: rollup
tidy: Distinguish between two different meanings of "style file"
This file contains code that uses “style file” to mean “CSS file”, and other code that uses “style file” to mean “this file, which implements the style checker”.
That's very confusing, so it's easier to just say *CSS file* or *this file* as appropriate.
No functional change.
Update TRPL to add new Chapter 17: Async and Await
- Add support to `rustbook` to pass through the `-L`/`--library-path` flag to `mdbook` so that references to the `trpl` crate
- Build the `trpl` crate as part of the book tests. Make it straightforward to add other such book dependencies in the future if needed by implementing that in a fairly general way.
- Update the submodule for the book to pull in the new chapter on async and await, as well as a number of other fixes. This will happen organically/automatically in a week, too, but this lets me group this change with the next one:
- Update the compiler messages which reference the existing chapters 17–20, which are now chapters 18-21. There are only two, both previously referencing chapter 18.
- Update the UI tests which reference the compiler message outputs.
finish `Reveal` removal
After #133212 changed the `TypingMode` to be the only source of truth, this entirely rips out `Reveal`.
cc #132279
r? `@compiler-errors`
Without this change:
$ ./x test --set build.vendor=true src/doc/book
# (lots of output)
error: failed to select a version for the requirement `futures = "^0.3"` (locked to 0.3.30)
candidate versions found which didn't match: 0.3.31, 0.3.27
location searched: directory source `/Users/chris/dev/rust-lang/rust/vendor` (which is replacing registry `crates-io`)
required by package `trpl v0.2.0 (/Users/chris/dev/rust-lang/rust/src/doc/book/packages/trpl)`
perhaps a crate was updated and forgotten to be re-vendored?
Build completed unsuccessfully in 0:01:19
With this change:
$ ./x test --set build.vendor=true src/doc/book
# (lots of build output)
Testing stage1 mdbook src/doc/book (aarch64-apple-darwin)
finished in 86.949 seconds
Build completed successfully in 0:04:05
# Conflicts:
# src/bootstrap/src/core/build_steps/vendor.rs
Since TRPL now depends on a `trpl` crate, the test needs to be able to
build that crate to run mdbook against it, and also to invoke mdbook
with `--library-path` in that case. Use the support for that flag added
to `rustbook` in the previous change to invoke it with the path to the
dependencies it will need to run `rustdoc` tests which reference `trpl`.
Co-authored-by: Onur Özkan <onurozkan.dev@outlook.com>
This makes it possible to test an mdbook which has dependencies other
than the direct crate for the book itself, e.g. the `trpl` crate used in
_The Rust Programming Language_.
This also incorporates a number of other changes and fixes which would
normally have been part of the automatic update, but which were blocked
from landing because of the changes required to support shipping a crate
as part of the chapter, along with those changes.
Warn if `rust.download-rustc = true` is used with
`rust.debug-assertions` as alt CI rustc is not currently built with
debug assertions (not to be confused with LLVM assertions).
Fix missing submodule in `./x vendor`
The `src/tools/rustc-perf` submodule is needed for vendoring because it is included in the vendor set.
To test this:
1. Get a fresh clone of `rust-lang/rust`
2. `./x vendor`
generate-copyright: Now generates a library file too.
We only run reuse once, so the output has to be filtered to find only the files that are relevant to the library tree.
Outputs COPYRIGHT.html and COPYRIGHT-library.html.
The license-metadata.json file is also now in the tree. We need a CI tool to check that it's correct.
r? kobzol
Remaining steps:
* [ ] Teach CI to double-check the license-metadata.json file is correct
* [ ] Add the COPYRIGHT.html and COPYRIGHT-license.html to the releases
Stabilize the 2024 edition
This stabilizes the 2024 edition for Rust 1.85, scheduled to be released on February 20, 2025. 🎉
cc tracking issue: https://github.com/rust-lang/rust/issues/117258
There is a fair amount of follow-up work after this that I am working on (various docs, cargo, rustfmt, etc.), and this is will unblock those other changes.
Rollup of 8 pull requests
Successful merges:
- #133238 (re-export `is_loongarch_feature_detected`)
- #133288 (Support `each_ref` and `each_mut` in `[T; N]` in constant expressions.)
- #133311 (Miri subtree update)
- #133313 (Use arc4random of libc for RTEMS target)
- #133319 (Simplify `fulfill_implication`)
- #133323 (Bail in effects in old solver if self ty is ty var)
- #133330 (library: update comment around close())
- #133337 (Fix typo in `std:🧵:Scope::spawn` documentation.)
r? `@ghost`
`@rustbot` modify labels: rollup
[AIX] change system dynamic library format
Historically on AIX, almost all dynamic libraries are distributed in `.a` Big Archive Format which can consists of both static and shared objects in the same archive (e.g. `libc++abi.a(libc++abi.so.1)`). During the initial porting process, the dynamic libraries are kept as `.a` to simplify the migration, but semantically having an XCOFF object under the archive extension is wrong. For crate type `cdylib` we want to be able to distribute the libraries as archives as well.
We are migrating to archives with the following format:
```
$ ar -t lib<name>.a
lib<name>.so
```
where each archive contains a single member that is a shared XCOFF object that can be loaded.
This moves the list of submodules needed to vendor close to the list of
cargo workspaces with the intent to help ensure they keep up-to-date and
in sync.
