Revert tearing changes to `dbg!`
Since the primary change to `dbg!` in rust-lang/rust#149869, we've been chasing a few regressions:
* rust-lang/rust#153850, fixed by rust-lang/rust#154074
* rust-lang/rust#154988, fixed by rust-lang/rust#154994
* rust-lang/rust#155902, proposed fix in rust-lang/rust#155915
We already reverted this once, on beta only to prevent these regressions from shipping in 1.95.
In that most recent PR, we decided that it would be better to revert `dbg!` to its original state everywhere (`main` and 1.96-`beta`), and then we can consider it from scratch later. So here I've reverted the change and its fixes, but kept the regression tests, including the pending one.
cc @joboet @dianne @rust-lang/libs
@rustbot label beta-nominated
[rustdoc] Move `span_map` file to the right folder
This file should at the same level as `highlight.rs` and `macro_expansion.rs` as it doesn't do anything in `render`.
r? @yotamofek
Add support for xray in aarch64 unknown none targets
I am currently working on an embedded project and use the target `aarch64-unknown-none`, which I want to profile.
I found the following compiler flag `-Z instrument-xray` (https://doc.rust-lang.org/unstable-book/compiler-flags/instrument-xray.html) available and I locally built a toolchain that sets the `supports_xray: true` option in `TargetOptions` for `compiler/rustc_target/src/spec/targets/aarch64_unknown_none.rs`.
Using this toolchain in `rustup` I am able to use the instrumentation pass and I verified that the disassembly looks as what I want.
I understand that it isn't available upstream while being supported due to the separate runtime library which has to be linked (e.g., https://www.llvm.org/docs/XRay.html#xray-runtime-library), which is not available for `aarch64-unknown-none`.
I argue that someone who cross-compiles for `aarch64-unknown-none` would be okay with writing a separate runtime library themselves, which I intend to do.
As far as I understood it is not necessarily required to have a runtime library at this point, i.e., the user of this API should link it, e.g., from their `build.rs` file using `cargo::rustc-link-lib=LIB` if there is an XRay LIB available for the respective target, e.g., `clang+llvm-19.1.1-aarch64-linux-gnu/lib/clang/19/lib/aarch64-unknown-linux-gnu/libclang_rt.xray-fdr.a` (which afaik there isn't for `aarch64-unknown-none`) and do "configuration as code" of XRay's options.
It should not be part of the compiler, because the instrumentation and the runtime library are completely decoupled. One can modify the instrumented code by the compiler pass however one wants to, this again pushes me into the direction of telling the developer to bring his own runtime library.
I would like to bring my change that enables this instrumentation back into upstream to facilitate my developer experience.
ci: Add dist-aarch64-freebsd
Add scripts to build the aarch64-unknown-freebsd target in CI.
Implements MCP: https://github.com/rust-lang/compiler-team/issues/961
There is currently the issue of FreeBSD version support. See the following thread for more details:
https://github.com/rust-lang/rust/pull/132228
The current version supported by rust is FreeBSD 12, which is already EOL. This means it is no longer possible to download FreeBSD releases from their servers. The aarch64 build is not mirrored on the Rust servers, which is why I couldn't match the version used by already existing CI scripts and had to change this one to FreeBSD 13. FreeBSD 13 itself will be EOL a month from now, on April 30th. We might want to put aarch64 FreeBSD builds on the Rust mirror and update the support across the board to FreeBSD 14 prior to merging this.
1. Blocking `connect`s which fail no longer only return EINPROGRESS but
instead return the correct error code.
2. Manually reading SO_ERROR outside of `ensure_connected` no longer
allows the socket to be upgraded to `Connected` despite the `connect`
failing.
3. Introduced new `ConnectionFailed` state to disallow actions on
sockets with a failed `connect`.
test new solver on CI until stabilization
We need the new solver to be able to build the stdlib, and this has regressed in the recent past. Things are broken right now, and we want to ensure this keeps working until stabilization later this year.
I've added this to the `x86_64-gnu-llvm-XX` job (note no `-1/2/3` suffix) so it's run on PR and auto CI, and because it's roughly the fastest of these builders, though maybe the aarch64 llvm 1 and 2 are slightly faster.
Building the stage 1 `./x build library/` is generally quite quick, a couple minutes at most.
The new solver fix to build std is from @lcnr [on zulip](https://rust-lang.zulipchat.com/#narrow/channel/364551-t-types.2Ftrait-system-refactor/topic/weekly.20sync.2Fupdates/near/591998234).
r? @marcoieni
Include vendored sources in the rust-src component
In the future this can be used by build-std, but until then it is still useful for allowing rust-analyzer to work offline.
This increases the unpacked size by 24MB (from 116MB to 140MB) and the compressed size by only 2MB (from 18MB to 20MB)
Disable rust-analyzer tests on LLVM 21
The rust-analyzer tests have been frequently failing with a SIGSEGV on CI in the LLVM 21 runners. In my investigation, this seems to be fixed with LLVM 22. It was suggested that we should just disable these tests.
There wasn't a particularly convenient way to detect if this is running with LLVM 21, so I decided to just check the CI_JOB_NAME which contains the image name which in our case includes the string "llvm-21".
Fixes https://github.com/rust-lang/rust/issues/156460
explicit tail calls: ignore some tests on unsupported LLVM targets
Fixes https://github.com/rust-lang/rust/issues/148748
Add ignore derivatives to two tests that cause the most platforms to fail, there are two reasons:
All tests involving `musttail` should fail on these platforms due to poor support overall by LLVM, but since they have low usage and supposedly already have many tests failing we limit ignores to the two "worst" tests.
```
//@ ignore-aix
//@ ignore-csky
//@ ignore-mips
//@ ignore-mips64
//@ ignore-powerpc
//@ ignore-powerpc64
//@ ignore-thumb
```
aix/powerpc issue: https://github.com/llvm/llvm-project/issues/187119
thumb issue: https://github.com/llvm/llvm-project/issues/73167
mips has been fixed but it is in a different LLVM version than what is pinned by Rust: https://github.com/llvm/llvm-project/issues/57795
These were caused by argument/returns that do not fit in registers (e.g., indirect), they had a fix but were reverted due to lifetime issues:
```
//@ ignore-riscv64
//@ ignore-loongarch32
//@ ignore-loongarch64
```
RISC-V had a fix which got reverted: https://github.com/llvm/llvm-project/pull/191508
LoongArch fix also got reverted: https://github.com/llvm/llvm-project/pull/191525
Also add missing compiletest directive names for `ignore-csky`, `ignore-mips`, and `ignore-mips64`.
r? folkertdev
ci: Update FreeBSD version to FreeBSD 14
FreeBSD 12 & 13 are now EOL. The decision to move to FreeBSD 13 was not implemented due to the issues with the toolchain. Now that FreeBSD 14 is the most recent supported version, we should use it for builds in CI.
Split `LintExpectationId`s
This PR makes clearer where stable and unstable `LintExpectationIds` can occur, plus a few other small cleanups. Details in individual commits.
r? @GuillaumeGomez
Remove redundant information in `rustc_abi::Variants`
Follow-up to rust-lang/rust#151040; partially addresses rust-lang/rust#113988.
Replaces the nested `LayoutData` in `Variants::Multiple` by a new, smaller `VariantLayout` struct, and adjust `LayoutData::for_variant`and the layout algorithm in consequence.
This PR is best reviewed commit-by-commit.
The rust-analyzer tests have been frequently failing with a SIGSEGV on
CI in the LLVM 21 runners. In my investigation, this seems to be fixed
with LLVM 22. It was suggested that we should just disable these tests.
There wasn't a particularly convenient way to detect if this is running
with LLVM 21, so I decided to just check the CI_JOB_NAME which contains
the image name which in our case includes the string "llvm-21".
Fixes https://github.com/rust-lang/rust/issues/156460
[style] rustfmt `match`es with comments in or-patterns
Using https://github.com/rust-lang/rustfmt/pull/6893, I reformatted the whole codebase. The result is that `match`es that *should have* been formatted under normal circumstances but are getting skipped now got their expected format. These match expressions were being entirely skipped because they contain or-patterns with comments in between patterns, causing rustfmt to bail out entirely. The or-patterns with comments themselves remain untouched, but now the match arm bodies and other patterns without comments do get formatted under that PR.
Because the fix in rustfmt isn't landed yet, I reworked some of the or-patterns with comments so that formatting doesn't regress. Tried doing this only in larger blocks that are more likely to regress in the meantime.
(Introduced and) removed a bunch of stray backticks \` likely left after an editor autoclosed the intended closing \`, resulting in <code>\`name\`\`</code> in comments.
rustdoc: properly support macros with multiple kinds
Since it seems like I can't reopen https://github.com/rust-lang/rust/pull/145458, opening this one. Although, it's the same PR minus the last new commit to handle a comment that was left unresolved in the original PR. All relevant details are still in the original PR though.
It's an alternative (and likely a take-over) of https://github.com/rust-lang/rust/pull/148005 since lang-team rejected the idea to add documentation on macro branches, making the multiple files approach less suitable.
This implements rust-lang/rust#145153 in rustdoc. This PR voluntarily doesn't touch anything related to intra-doc links, I'll send a follow-up if needed.
So now about the implementation itself: this is a weird case where a macro can be different things at once but still only gets one file generated. I saw two ways to implement this:
1. Handle `ItemKind::Macro` differently and iter through its `MacroKinds` values.
2. Add new placeholder variants in the `ItemKind` enum, which means that when we encounter them in rendering, we need to ignore them. It also makes the `ItemKind` enum bigger (and also needs more code to be handled). Another downside is that it needs to be handled in the JSON output.
Now there was an interesting improvement that came with this PR in the `html::render::print_item::item_module` function: I simplified its implementation and split the different parts in a `HashMap` where the key is the item type. So then, we can just iterate through the keys and open/close the section at each iteration instead of keeping an `Option<section>` around.
From RFCs:
* https://github.com/rust-lang/rust/pull/144579
* https://github.com/rust-lang/rust/pull/145208
derive:
<img width="442" height="327" alt="Screenshot From 2026-04-18 03-11-40" src="https://github.com/user-attachments/assets/f69587a0-8a2b-4080-bc8a-b63dd18f21c1" />
attr:
<img width="442" height="327" alt="Screenshot From 2026-04-18 03-11-31" src="https://github.com/user-attachments/assets/bf9b235a-9d2f-435c-a91e-167562df6b68" />
both:
<img width="442" height="327" alt="Screenshot From 2026-04-18 03-11-50" src="https://github.com/user-attachments/assets/b7e8b3c6-eb99-495b-bdf9-17ba8fb4da0d" />
r? @notriddle
CI is currently down because apt is unable to access the repo at
dilos.org. It is failing inside the fortanix install script which tries
to run apt-get with the error:
```
5.679 E: Failed to fetch https://apt.dilos.org/dilos/dists/dilos2/InRelease 403 Forbidden [IP: 116.202.240.188 443]
```
These lines in the Dockerfile were added when Solaris builds were merged
into dist-various-2 in https://github.com/rust-lang/rust/pull/45001.
However, Solaris builds were split off in
https://github.com/rust-lang/rust/pull/138699. In that PR, these lines
adding the dilos repository weren't removed.
AFAICT, these are no longer necessary.
`LintExpectationId` has two variants, `Unstable` and `Stable`. There are
some places where both variants are possible, but there are also places
where only one of `Unstable` or `Stable` is possible.
This commit encodes this into the type system by introducing
new types `UnstableLintExpectationId` and `StableLintExpectationId`. The
variants of `LintExpectationId` now enclose these. This makes it clearer
what values are possible where.
Other things of note:
- `LintLevelsProvider` gets an associated type and some method changes.
- `LintContext` gets an associated type.
- `LevelSpec` is made generic. `UnstableLevelSpec` and `StableLevelSpec`
typedefs are added.
- The unstable types are now guaranteed by the type system to never be
stably hashed. Previously this was a runtime check.
bors