Enable thumb interworking on ARMv7A/R and ARMv8R bare-metal targets
This flag enables the `#[instruction_set(arm::t32)]` for the armv7a/armv7r/armv8r targets, which all support Thumb interwork but were missing this flag.
Target maintainers are `@chrisnc,` `@rust-lang/arm-maintainers,` `@rust-embedded/arm` (including me).
`region_scope_tree`: Rewrite a `loop` as tail recursion
This addresses https://github.com/rust-lang/rust/pull/146098#discussion_r2652130775, hopefully making `record_subexpr_extended_temp_scopes` a bit more legible.
I removed a `debug!` in the process, since the function it calls every iteration, [`ScopeTree::record_extended_temp_scope`](2848c2ebe9/compiler/rustc_middle/src/middle/region.rs (L264-L271)), does the same `debug!`. Keeping the behavior of having an additional `debug!` for the top-level expression would hurt legibility, and having a duplicate `debug!` at each iteration seems excessive. No information is lost from the debug output, so I think it's fine to just have the inner `debug!`s.
r? BoxyUwU or anyone
`crate::io::Result` → `io::Result` in most places
I don't know why many places refer to the type as `crate::io::Result` when `crate::io` is already imported.
fix(bootstrap/dist)!: change dist path for `rustc-docs` to avoid clashing
Closesrust-lang/rust#75833, part of https://github.com/rust-lang/rustup/issues/3717:
> I'd like to know if we can assign another folder name to `rustc-docs`?
> [...]
> [`@ThePuzzlemaker](https://github.com/ThePuzzlemaker)'s` `share/doc/rust/html/nightly-rustc` does look a bit weird to me (`nightly-rustc` has nothing to do with the current `rustc`, i.e. the Rustc Book, but they somehow appear similar just looking at the names).
>
> I personally would like to see something like `share/doc/rust/html/rustc-docs` or `share/doc/rust/html/rustc-api` for this component.
_https://github.com/rust-lang/rust/issues/75833#issuecomment-2002503223_
The TLDR is that currently the "rustc book"'s path clashes with "rustc APIs" (i.e. `rustc-docs`), so we change the path of the latter to make it distributable via rustup.
I'm new to `bootstrap` so please feel free to point out any inconsistencies or any extra work I'll need to do to fully land this somewhat breaking change.
Remove `feature(string_deref_patterns)`
The older `string_deref_patterns` feature has been superseded by the newer and more general `deref_patterns` feature. Removing string-deref-patterns allows us to get rid of a few tricky special cases in match lowering, which are different from the special cases used by deref-patterns.
The handful of existing tests for `string_deref_patterns` have been migrated to use `deref_patterns` instead. Current nightly users of the older feature should hopefully be able to migrate to the newer feature without too much trouble.
Note that `deref_patterns` is currently marked as an “incomplete” feature, because it doesn't have an accepted RFC. But `string_deref_patterns` doesn't appear to have ever had an accepted RFC either, so arguably it should have been marked incomplete too.
---
- Tracking issue for both features: https://github.com/rust-lang/rust/issues/87121
- Original implementation: https://github.com/rust-lang/rust/pull/98914
- [Zulip thread: Can we remove `#![feature(string_deref_patterns)]`?](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Can.20we.20remove.20.60.23!.5Bfeature.28string_deref_patterns.29.5D.60.3F/with/565787352)
RISC-V: Implement (Zkne or Zknd) intrinsics correctly
On rust-lang/stdarch#1765, it has been pointed out that two RISC-V (64-bit only) intrinsics to perform AES key scheduling have wrong target feature.
`aes64ks1i` and `aes64ks2` instructions require *either* Zkne (scalar cryptography: AES encryption) or Zknd (scalar cryptography: AES decryption) extension (or both) but corresponding Rust intrinsics (in `core::arch::riscv64`) required *both* Zkne and Zknd extensions.
An excerpt from the original intrinsics:
```rust
#[target_feature(enable = "zkne", enable = "zknd")]
```
To fix that, we need to:
1. Represent a condition where *either* Zkne or Zknd is available and
2. Workaround an issue: `llvm.riscv.aes64ks1i` / `llvm.riscv.aes64ks2` LLVM intrinsics require either Zkne or Zknd extension.
This PR attempts to resolve them by:
1. Adding a perma-unstable RISC-V target feature: `zkne_or_zknd` (implied from both `zkne` and `zknd`) and
2. Using inline assembly to construct machine code directly (because `zkne_or_zknd` alone cannot imply neither Zkne nor Zknd, we cannot use LLVM intrinsics).
The author confirmed that we can construct an AES key scheduling function with decent performance using fixed `aes64ks1i` and `aes64ks2` intrinsics (with optimization enabled).
Corretly link URL in internal Windows docs
```
warning: this URL is not a hyperlink
--> library/std/src/sys/pal/windows/mod.rs:337:5
|
337 | /// https://docs.microsoft.com/en-us/cpp/intrinsics/fastfail
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: bare URLs are not automatically turned into clickable links
= note: `#[warn(rustdoc::bare_urls)]` on by default
help: use an automatic link instead
|
337 | /// <https://docs.microsoft.com/en-us/cpp/intrinsics/fastfail>
| + +
```
Allow inline calls to offload intrinsic
Removes explicit insertion point handling and recovers the pointer at the end of the saved basic block.
r? `@ZuseZ4`
fixes: https://github.com/rust-lang/rust/issues/150413
Port `#[instruction_set]` to attribute parser
Please note the test changes, and deprecation of `E0778` and `E0779`
In my opinion, all errors related to this attribute are improved I think, except for if you have `#[instruction_set(arm::)]` in which case there's an `error: expected identifier, found <eof>`, which is quite unhelpful I think, but this seems to be a limitation of the general attribute parsing flow
r? `@JonathanBrouwer`
```
warning: this URL is not a hyperlink
--> library/std/src/sys/pal/windows/mod.rs:337:5
|
337 | /// https://docs.microsoft.com/en-us/cpp/intrinsics/fastfail
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: bare URLs are not automatically turned into clickable links
= note: `#[warn(rustdoc::bare_urls)]` on by default
help: use an automatic link instead
|
337 | /// <https://docs.microsoft.com/en-us/cpp/intrinsics/fastfail>
| + +
```
Make inliner cycle detection a fallible process
The query `mir_callgraph_cyclic` is supposed to find _all_ callees that _may_ lead to a recursive call back to the given `LocalDefId`. But that query was built using a function which recurses through the call graph and tries to locally handle hitting the recursion limit during the walk. That is wrong. If the recursion limit is encountered, the set may be incomplete and thus useless. If we hit the recursion limit the only correct thing to do is bail.
Some benchmarks improve because for some functions we will bail out of the call graph walk faster. Some benchmarks regress because we do less inlining, but that is quite rare with the default recursion depth.
Originally I thought this might be a fix for https://github.com/rust-lang/rust/issues/131960, but it turns out that it is _actually_ a fix for https://github.com/rust-lang/rust/issues/146998.
Example
---
```rust
trait T {}
impl T for {}
```
**Before this PR**
```rust
trait T {}
impl T for {}
// ^ dyn
```
**After this PR**
```rust
trait T {}
impl T for {}
```
Update cargo submodule
9 commits in 94c368ad2b9db0f0da5bdd8421cea13786ce4412..b54051b1505281ec7a45a250140a0ff25d33f319
2025-12-26 19:39:15 +0000 to 2025-12-30 20:35:52 +0000
- fix(log): add `dependencies` field to `UnitRegistered` (rust-lang/cargo#16448)
- Implement fine grain locking for `build-dir` (rust-lang/cargo#16155)
- feat(resolver): List features when no close match (rust-lang/cargo#16445)
- feat(report): new command `cargo report sessions` (rust-lang/cargo#16428)
- feat (patch): Display where the patch was defined in patch-related error messages (rust-lang/cargo#16407)
- test(build-rs): Reduce from 'build' to 'check' where possible (rust-lang/cargo#16444)
- feat(toml): TOML 1.1 parse support (rust-lang/cargo#16415)
- feat(report): support --manifest-path in `cargo report timings` (rust-lang/cargo#16441)
- fix(vendor): recursively filter git files in subdirectories (rust-lang/cargo#16439)
r? ghost
std: sys: fs: uefi: Ignore "." and ".." when reading directory
- At least in Unix, "." and ".." are not returned as a directory entry. So ignore these in UEFI as well.
- Will also allow using the `remove_dir_all` implementation from `sys/fs/common`.
Rollup of 3 pull requests
Successful merges:
- rust-lang/rust#150058 (Enable file locking support for Hurd)
- rust-lang/rust#150420 (Do not spill operand debuginfo to stack for AArch64 SVE predicates `<vscale x N x i1>` where `N != 16`)
- rust-lang/rust#150501 (Fix Typos in Platform Support Tables)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix Typos in Platform Support Tables
3 recently demoted targets had their entries moved to the tier 3 table without adjusting for the extra "host" column, this PR adds an empty column so they display correctly.
2 recently promoted targets had the opposite problem, also fixed.
While doing that I noticed that empty columns were represented inconsistently throughout the file so I normalized them all to be 2 spaces, which seemed to be the majority opinion (139 instances vs 5 for 1 space and 19 for 3 spaces).
Closes: rust-lang/rust#150499
Enable file locking support for Hurd
like Illumos (rust-lang/rust#148322) and aix (rust-lang/rust#148619), Hurd was missed when originally
introducing locking gates per target OS in rust-lang/rust#132977. building rustc on Hurd was
broken as a result since 1.91.
At least in Unix, "." and ".." are not returned as a directory entry. So
ignore these in UEFI as well.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
Rollup of 2 pull requests
Successful merges:
- rust-lang/rust#150422 (mir_build: Add a `SliceLenOp` enum for use by slice-length cases/tests)
- rust-lang/rust#150509 (Adds a regression test for rust-lang/rust#137823)
r? `@ghost`
`@rustbot` modify labels: rollup
Adds a regression test for #137823
Adds a regression test for rust-lang/rust#137823. The test ensures that recursive generic function instantiation properly triggers the recursion limit error instead of ICE-ing with `type variables should not be hashed`.
Closesrust-lang/rust#137823
mir_build: Add a `SliceLenOp` enum for use by slice-length cases/tests
The main change in this PR introduces a `SliceLenOp` enum, to be used by the enum variants for slice-length tests in match lowering.
Slice-length tests must distinguish between `==` tests, and `>=` tests. The existing code represents this distinction with either a boolean (in `TestableCase`) or a `mir::BinOp` (in `TestKind`). Using a dedicated enum makes it easier to see what the two possible values represent.
This PR also includes a few relevant cleanups that would otherwise conflict.
r? Nadrieril
