This recently spuriously failed in a rollup, so I think we can afford to
increase the base timeout and the amount of time slept for to provide
a much wider margin for the timeout to be reached.
Sized Hierarchy: Part I
This patch implements the non-const parts of rust-lang/rfcs#3729. It introduces two new traits to the standard library, `MetaSized` and `PointeeSized`. See the RFC for the rationale behind these traits and to discuss whether this change makes sense in the abstract.
These traits are unstable (as is their constness), so users cannot refer to them without opting-in to `feature(sized_hierarchy)`. These traits are not behind `cfg`s as this would make implementation unfeasible, there would simply be too many `cfg`s required to add the necessary bounds everywhere. So, like `Sized`, these traits are automatically implemented by the compiler.
RFC 3729 describes changes which are necessary to preserve backwards compatibility given the introduction of these traits, which are implemented and as follows:
- `?Sized` is rewritten as `MetaSized`
- `MetaSized` is added as a default supertrait for all traits w/out an explicit sizedness supertrait already.
There are no edition migrations implemented in this, as these are primarily required for the constness parts of the RFC and prior to stabilisation of this (and so will come in follow-up PRs alongside the const parts). All diagnostic output should remain the same (showing `?Sized` even if the compiler sees `MetaSized`) unless the `sized_hierarchy` feature is enabled.
Due to the use of unstable extern types in the standard library and rustc, some bounds in both projects have had to be relaxed already - this is unfortunate but unavoidable so that these extern types can continue to be used where they were before. Performing these relaxations in the standard library and rustc are desirable longer-term anyway, but some bounds are not as relaxed as they ideally would be due to the inability to relax `Deref::Target` (this will be investigated separately).
It is hoped that this is implemented such that it could be merged and these traits could exist "under the hood" without that being observable to the user (other than in any performance impact this has on the compiler, etc). Some details might leak through due to the standard library relaxations, but this has not been observed in test output.
**Notes:**
- Any commits starting with "upstream:" can be ignored, as these correspond to other upstream PRs that this is based on which have yet to be merged.
- This best reviewed commit-by-commit. I've attempted to make the implementation easy to follow and keep similar changes and test output updates together.
- Each commit has a short description describing its purpose.
- This patch is large but it's primarily in the test suite.
- I've worked on the performance of this patch and a few optimisations are implemented so that the performance impact is neutral-to-minor.
- `PointeeSized` is a different name from the RFC just to make it more obvious that it is different from `std::ptr::Pointee` but all the names are yet to be bikeshed anyway.
- `@nikomatsakis` has confirmed [that this can proceed as an experiment from the t-lang side](https://rust-lang.zulipchat.com/#narrow/channel/435869-project-goals/topic/SVE.20and.20SME.20on.20AArch64.20.28goals.23270.29/near/506196491)
- FCP in https://github.com/rust-lang/rust/pull/137944#issuecomment-2912207485Fixesrust-lang/rust#79409.
r? `@ghost` (I'll discuss this with relevant teams to find a reviewer)
Set elf e_flags on ppc64 targets according to abi
(This PR contains the non user-facing changes of https://github.com/rust-lang/rust/pull/142321)
Fixes https://github.com/rust-lang/rust/issues/85589 by making sure that ld.lld errors out instead of generating a broken binary.
Basically the problem is that ld.lld assumes that all ppc64 object files with e_flags=0 are object files which use the ELFv2 ABI (this here is the check https://github.com/llvm/llvm-project/blob/main/lld/ELF/Arch/PPC64.cpp#L639).
This pull request sets the correct e_flags to indicate the used ABI so ld.lld errors out when encountering ELFv1 ABI files instead of generating a broken binary.
For example compare code generation for this program (file name ``min.rs``):
```rust
#![feature(no_core, lang_items, repr_simd)]
#![crate_type = "bin"]
#![no_core]
#![no_main]
#[lang = "sized"]
trait Sized {}
#[lang = "copy"]
trait Copy {}
#[lang = "panic_cannot_unwind"]
pub fn panic() -> ! {
loop {}
}
pub fn my_rad_unmangled_function() {
loop {}
}
pub fn my_rad_function() {
loop {}
}
#[no_mangle]
pub fn _start() {
my_rad_unmangled_function();
my_rad_function();
}
```
Compile with ``rustc --target=powerpc64-unknown-linux-gnu -C linker=ld.lld -C relocation-model=static min.rs``
Before change:
```
$ llvm-objdump -d min
Disassembly of section .text:
000000001001030c <.text>:
...
10010334: 7c 08 02 a6 mflr 0
10010338: f8 21 ff 91 stdu 1, -112(1)
1001033c: f8 01 00 80 std 0, 128(1)
10010340: 48 02 00 39 bl 0x10030378 <_ZN3min25my_rad_unmangled_function17h7471c49af58039f5E>
10010344: 60 00 00 00 nop
10010348: 48 02 00 49 bl 0x10030390 <_ZN3min15my_rad_function17h37112b8fd1008c9bE>
1001034c: 60 00 00 00 nop
...
```
The branch instructions ``bl 0x10030378`` and ``bl 0x10030390`` are jumping into the ``.opd`` section which is data. That is a broken binary (because fixing those branches is the task of the linker).
After change:
```
error: linking with `ld.lld` failed: exit status: 1
|
= note: "ld.lld" "/tmp/rustcNYKZCS/symbols.o" "<1 object files omitted>" "--as-needed" "-L" "/tmp/rustcNYKZCS/raw-dylibs" "-Bdynamic" "--eh-frame-hdr" "-z" "noexecstack" "-L" "<sysroot>/lib/rustlib/powerpc64-unknown-linux-gnu/lib" "-o" "min" "--gc-sections" "-z" "relro" "-z" "now"
= note: some arguments are omitted. use `--verbose` to show all linker arguments
= note: ld.lld: error: /tmp/rustcNYKZCS/symbols.o: ABI version 1 is not supported
```
Which is correct because ld.lld doesn't support ELFv1 ABI.
Revert overeager warning for misuse of `--print native-static-libs`
In a PR to emit warnings on misuse of `--print native-static-libs`, we did not consider the matter of composing parts of build systems. If you are not directly invoking rustc, it can be difficult to know when you will in fact compile a staticlib, so making sure uses `--print native-static-lib` correctly can be just a nuisance.
Next cycle we can reland a slightly more narrowly focused variant or one that focuses on `--emit` instead of `--print native-static-libs`. But in its current state, I am not sure the warning is very useful.
Make sure to propagate result from `visit_expr_fields`
We weren't propagating the `ControlFlow::Break` out of a struct field, which means that the solution implemented in rust-lang/rust#130443 didn't work for nested fields.
Fixesrust-lang/rust#142525.
Update books
## rust-lang/book
1 commits in 634724ea85ebb08a542970bf8871ac8b0f77fd15..4433c9f0cad8460bee05ede040587f8a1fa3f1de
2025-06-03 16:34:00 UTC to 2025-06-03 16:34:00 UTC
- Chapter 11 from tech review (rust-lang/book#4391)
## rust-lang/reference
10 commits in 8e0f593a30f3b56ddb0908fb7ab9249974e08738..d4c66b346f4b72d29e70390a3fa3ea7d4e064db1
2025-06-13 17:05:11 UTC to 2025-06-03 21:28:42 UTC
- Align pattern destructuring with rest of patterns documentation (rust-lang/reference#1853)
- Use extern "system" instead of "stdcall" in example (rust-lang/reference#1854)
- Mention that `thiscall` is a 32-bit calling convention (rust-lang/reference#1855)
- Add doc for keylocker target features (rust-lang/reference#1829)
- Add doc for `sha512`, `sm3` and `sm4` target features (rust-lang/reference#1830)
- Fix(typo): 'though' should be 'through' (rust-lang/reference#1850)
- intro note: make text more simple (rust-lang/reference#1844)
- nit: add missing period (rust-lang/reference#1843)
- add a warning about using `safe` on extern c-variadic functions (rust-lang/reference#1839)
- remove the `safe` keyword from a c-variadic foreign function. (rust-lang/reference#1838)
## rust-lang/rust-by-example
3 commits in 21f4e32b8b40d36453fae16ec07ad4b857c445b6..9baa9e863116cb9524a177d5a5c475baac18928a
2025-06-11 13:00:27 UTC to 2025-06-10 12:43:14 UTC
- introduce new ``@media`` query to set a higher content width on ultra wide screens (rust-lang/rust-by-example#1937)
- Fix syntax highligting (rust-lang/rust-by-example#1935)
- fix(rust-lang/rust#1656): update doc tests to use `playground` as the crate name (rust-lang/rust-by-example#1934)
Reject union default field values
Fixesrust-lang/rust#142555.
The [`default_field_values` RFC][rfc] does not specify that default field values may be used on `union`s, and it's not clear how default field values may be used with `union`s without an design extension to the RFC. So, for now, reject trying to use default field values with `union`s.
### Review notes
- The first commit adds the `union` with default field values test case to `tests/ui/structs/default-field-values/failures.rs`, where `union`s with default field values are currently accepted.
- The second commit rejects trying to supply default field values to `union` definitions.
- When `default_field_values` feature gate is disabled, we show the feature gate error when the user tries to write `union`s with default field values. When the feature gate is enabled, we reject this usage with
> unions cannot have default field values
``@rustbot`` label: +F-default_field_values
[rfc]: https://rust-lang.github.io/rfcs/3681-default-field-values.html
Refine run-make test ignores due to unpredictable `i686-pc-windows-gnu` unwind mechanism
Closesrust-lang/rust#128911. This PR *re-enables* the `dump-ice-to-disk` test and the unstable feature usage metrics tests for {x86_64,i686} Windows MSVC hosts and x86_64 Windows GNU host. I'll keep an eye out for these tests, and will broaden the ignores if this test is still flaky on not just `i686-pc-windows-gnu`.
r? mati865
try-job: x86_64-msvc-1
try-job: i686-msvc-1
try-job: x86_64-mingw-1
Manually invalidate caches in SimplifyCfg.
The current `SimplifyCfg` pass unconditionally invalidates CFG caches. This is unfortunate if there are no modifications that require this invalidation.
std: refactor explanation of `NonNull`
Fixesrust-lang/rust#141933
I cut out the excessive explanation and used an example to explain how to maintain invariance, but I think what is quoted in the *rust reference* in the document needs to be added with a more layman's explanation and example.
(I'm not sure if I deleted too much)
r? `@workingjubilee`
It isn't clear why the `Deref` impl isn't found for this in a stage two
build, but presumably relates to `rustc_middle::ty::RawList` containing
an extern type and `Deref` not yet being relaxed to `PointeeSized` (this
is technically a breaking change but unlikely to be one and will be
tested in a follow-up).
`nominal_obligations` calls `predicates_of` on a `Sized` obligation,
effectively elaborating the trait and making the well-formedness checking
machinery do a bunch of extra work checking a `MetaSized` obligation is
well-formed, but given that both `Sized` and `MetaSized` are built-ins,
if `Sized` is otherwise well-formed, so `MetaSized` will be.
As a performance optimization, skip elaborating the supertraits of
`Sized`, and if a `MetaSized` obligation is being checked, then look for
a `Sized` predicate in the parameter environment. This makes the
`ParamEnv` smaller which should improve compiler performance as it avoids
all the iteration over the larger `ParamEnv`.
These tests just need blessing, they don't have any interesting behaviour
changes.
Some of these tests have new errors because `LegacyReceiver` cannot be
proven to be implemented now that it is also testing for `MetaSized` -
but this is just a consequence of the other errors in the test.
This test case is a reduction from the `hwc` crate on GitHub, following a
crater run. It passes with the next solver but fails on the current
solver due to a known limitation of the current solver. It starts fails
on the current solver with the `sized_hierarchy` changes because `?Sized`
is now a proper bound.
It seems like generics from `non_lifetime_binders` don't have any default
bounds like normal generics, so all of the `?Sized` relaxations need
to be further relaxed with `PointeeSized` for this test to be the
equivalent of before.
These tests necessarily need to change now that `?Sized` is not
sufficient to accept extern types and `PointeeSized` is now necessary. In
addition, the `size_of_val`/`align_of_val` test can now be changed to
expect an error.
When printing impl headers in a diagnostic, the compiler has to account
for `?Sized` implying `MetaSized` and new `MetaSized` and `PointeeSized`
bounds.
Like `Sized` diagnostics, sorting `MetaSized` and `PointeeSized`
diagnostics last prevents earlier more useful diagnostics from being
skipped because there has already been error tainting.
Given the necessary additions of bounds to these traits and their impls
in the standard library, it is necessary to add `MetaSized` bounds to
the obligation which is proven as part of checking for dyn
dispatchability.
With `MetaSized` bounds replacing `?Sized` and being added as a
supertrait, the same relaxations applied to the standard library must be
applied to minicore.
Opting-out of `Sized` with `?Sized` is now equivalent to adding a
`MetaSized` bound, and adding a `MetaSized` or `PointeeSized` bound
is equivalent to removing the default `Sized` bound - this commit
implements this change in `rustc_hir_analysis::hir_ty_lowering`.
`MetaSized` is also added as a supertrait of all traits, as this is
necessary to preserve backwards compatibility.
Unfortunately, non-global where clauses being preferred over item bounds
(where `PointeeSized` bounds would be proven) - which can result in
errors when a `PointeeSized` supertrait/bound/predicate is added to some
items. Rather than `PointeeSized` being a bound on everything, it can
be the absence of a bound on everything, as `?Sized` was.
As core uses an extern type (`ptr::VTable`), the default `?Sized` to
`MetaSized` migration isn't sufficient, and some code that previously
accepted `VTable` needs relaxed to continue to accept extern types.
Similarly, the compiler uses many extern types in `rustc_codegen_llvm`
and in the `rustc_middle::ty::List` implementation (`OpaqueListContents`)
some bounds must be relaxed to continue to accept these types.
Unfortunately, due to the current inability to relax `Deref::Target`,
some of the bounds in the standard library are forced to be stricter than
they ideally would be.
