Fix `doc_cfg` feature for extern items
Part of rust-lang/rust#150268.
It only solves the extern items issue, but not the others listed in the issue. I will need to think about how to fix them nicely.
r? @Urgau
NVPTX: Drop support for old architectures and old ISAs
This is the implementation of [this MCP](https://github.com/rust-lang/compiler-team/issues/965#issuecomment-3837320262)
I believe it was said that no FCP was needed, but if that is incorrect then the FCP is anyway scheduled to finish in 2 days so it can in any case be merged then.
Make FileMetadata track Unix-specific fields as optional data. Advertise
STATX_* bits only for metadata that is actually available.
Add libc-fs coverage for statx on file paths, file
descriptors, and AT_EMPTY_PATH on pipes
compiletest: Overhaul the code for running an incremental test revision
The main goals of this overhaul are:
- Introduce a dedicated `IncrRevKind` enum for exhaustive matching.
- Eliminate any dependency on `PassMode` and `FailMode`.
- Use a single code path for all incremental revision kinds.
Separating incremental tests from the existing pass/fail enums should make it easier to overhaul the implementation of pass/fail expectations in UI tests.
---
Later on we might want to reintroduce more shared code paths for the different test modes, but for now the extra isolation makes it easier to clean up the individual modes.
r? jieyouxu
disable naked-dead-code-elimination test if no RET mnemonic is available
this test emit x86_64 specific ret asm instruction and should not be compiled on any other arch.
Document that CFI diverges from Rust wrt. ABI-compatibility rules
The CFI sanitizer is a sanitizer that checks that no ABI-incompatible function calls are made at runtime, but there is currently an unfortunate divergence between the Rust ABI-compatibility rules and what the CFI sanitizer checks. Thus, document that this divergence exists.
There are proposals for how we can align the ABI rules to eliminate this discrepancy, and I would like to follow through with those, but for now I think we can at least document that the discrepancy exists.
For further discussion please see [Re-evaluate ABI compatibility rules in light of CFI](https://github.com/rust-lang/unsafe-code-guidelines/issues/489) and [Can CFI be made compatible with type erasure schemes?](https://github.com/rust-lang/rust/issues/128728) and [`fn_cast!` macro](https://github.com/rust-lang/rust/issues/140803).
cc @rcvalle @samitolvanen @maurer @bjorn3 @RalfJung
Rendered:
<img width="956" height="391" alt="image" src="https://github.com/user-attachments/assets/410d3eaa-9476-4800-9ef8-bbb100a100c5" />
switch to v0 mangling by default on stable
Following rust-lang/rust#89117, rustc has defaulted to the v0 mangling scheme by default (since Nov 20th 2025). This surfaced two bugs:
- rust-lang/rust#138261 was a small ICE (found via fuzzing) where an implementation-internal namespace was missing for global assembly - this occurs with names instantiated within global assembly (that can happen inside constants)
- rust-lang/rust#134479 only occurs with unstable `generic_const_exprs`
Since there have been three-to-four months for users to find bugs with this mangling scheme on nightly, that the scheme has been waiting many years to be stabilised, and has been used successfully internally at Microsoft, Meta and Google for many years, this patch proposes stabilising the v0 mangling scheme on stable.
This patch does not propose removing the legacy mangling, it will remain usable on nightly as an escape-hatch if there are remaining bugs (though admittedly it would require switching to nightly for those on stable) - it is anticipated that this would be unlikely given current testing undergone by v0. Legacy mangling can be removed in another follow-up.
r? @wesleywiser
Rename the diagnostic item for `std::sync::mpsc::Receiver`
`MpscReceiver` aligns with `MpscSender`. The original name appears to not actually have been in use, for better or worse.
r? mejrs
Add infrastructure to query LLVM backend for specific assembly mnemonics
and use it in compiletest to conditionally run tests based on instruction
availability.
This fixes test failures with naked-dead-code-elimination which requires
the `RET` mnemonic.
Co-authored-by: Folkert de Vries <flokkievids@gmail.com>
`MpscReceiver` aligns with `MpscSender`. The original name appears to
not actually have been in use, for better or worse.
Along the way, sprinkle the attribute onto `mpmc::Receiver` and
`mpmc::Sender` too.
CI: rfl: move job forward to Linux v7.1-rc1
Linux v7.1 will have our new MSRVs: Rust 1.85.0 and `bindgen` 0.71.1.
r? @lqd @Kobzol
try-job: x86_64-rust-for-linux
@rustbot label A-rust-for-linux
@bors try
Change `ItemKind::Trait` to a field variant.
This changes `ItemKind::Trait` from an octuple(!!) to an enum variant with fields. Their names were chosen to match up with existing usage and minimize renaming.
I'm leaning towards renaming `ident` to `name` as well; let me know if that's desired.
CI: rfl: move job forward to Linux v7.0
This version contains both of the workarounds we had, thus remove them as well.
r? @lqd @Kobzol
try-job: x86_64-rust-for-linux
@rustbot label A-rust-for-linux
@bors try
Fix requires_lto targets needing lto set in cargo
Targets that set `requires_lto = true` were not actually using lto when compiling with cargo by default. They needed an extra `lto = true` in `Cargo.toml` to work.
Fix this by letting lto take precedence over the `embed_bitcode` flag when lto is required by a target.
If both these flags would be supplied by the user, an error is generated. However, this did not happen when lto was requested by the target instead of the user.
Fixesrust-lang/rust#148514
Tracking issue: rust-lang/rust#135024
Cleanups to `AttributeExt`
r? @mejrs
- Makes some functions take `ast::Attribute` instead of `impl AttributeExt`
- Remove `deprecation_note` from `AttributeExt`, since the two implementations are basically seperate
This commit expands the initialism UCRT on first use in the rusct book
chapter on the *-windows-gnullvm platform support, making the chapter
easier to understand. Microsoft, the originator of this technology in
Windows, expands it to Universal C Runtime[1]. The same expansion is
added to the chapter.
[1] https://learn.microsoft.com/en-us/cpp/porting/upgrade-your-code-to-the-universal-crt
Add intrinsic for launch-sized workgroup memory on GPUs
Workgroup memory is a memory region that is shared between all
threads in a workgroup on GPUs. Workgroup memory can be allocated
statically or after compilation, when launching a gpu-kernel.
The intrinsic added here returns the pointer to the memory that is
allocated at launch-time.
# Interface
With this change, workgroup memory can be accessed in Rust by
calling the new `gpu_launch_sized_workgroup_mem<T>() -> *mut T`
intrinsic.
It returns the pointer to workgroup memory guaranteeing that it is
aligned to at least the alignment of `T`.
The pointer is dereferencable for the size specified when launching the
current gpu-kernel (which may be the size of `T` but can also be larger
or smaller or zero).
All calls to this intrinsic return a pointer to the same address.
See the intrinsic documentation for more details.
## Alternative Interfaces
It was also considered to expose dynamic workgroup memory as extern
static variables in Rust, like they are represented in LLVM IR.
However, due to the pointer not being guaranteed to be dereferencable
(that depends on the allocated size at runtime), such a global must be
zero-sized, which makes global variables a bad fit.
# Implementation Details
Workgroup memory in amdgpu and nvptx lives in address space 3.
Workgroup memory from a launch is implemented by creating an
external global variable in address space 3. The global is declared with
size 0, as the actual size is only known at runtime. It is defined
behavior in LLVM to access an external global outside the defined size.
There is no similar way to get the allocated size of launch-sized
workgroup memory on amdgpu an nvptx, so users have to pass this
out-of-band or rely on target specific ways for now.
Tracking issue: rust-lang/rust#135516
The main goals of this overhaul are:
- Introduce a dedicated `IncrRevKind` enum for exhaustive matching.
- Eliminate any dependency on `PassMode` and `FailMode`.
- Use a single code path for all incremental revision kinds.
Separating incremental tests from the existing pass/fail enums should make it
easier to overhaul the implementation of pass/fail expectations in UI tests.
bors