This commit stabilizes RISC-V target features with following constraints:
* Describes a ratified extension.
* Implemented on Rust 1.88.0 or before.
Waiting for four+ version cycles seems sufficient.
* Does not disrupt current rustc's target feature + ABI handling.
It excludes "E" and all floating point-arithmetic extensions.
"Zfinx" family does not involve floating point registers but
not stabilizing for now to avoid possible confusion between
the "F" extension family.
* Not vector-related (floating point and integer).
While integer vector subsets should not cause any ABI issues
(as they don't use ABI-dependent floating point registers),
we need to discuss before stabilizing them.
* Supported by the lowest LLVM version supported by rustc (LLVM 20).
List of target features to be stabilized:
1. "b"
2. "za64rs" (no-RT)
3. "za128rs" (no-RT)
4. "zaamo"
5. "zabha"
6. "zacas"
7. "zalrsc"
8. "zama16b" (no-RT)
9. "zawrs"
10. "zca"
11. "zcb"
12. "zcmop"
13. "zic64b" (no-RT)
14. "zicbom"
15. "zicbop" (no-RT)
16. "zicboz"
17. "ziccamoa" (no-RT)
18. "ziccif" (no-RT)
19. "zicclsm" (no-RT)
20. "ziccrse" (no-RT)
21. "zicntr"
22. "zicond"
23. "zicsr"
24. "zifencei"
25. "zihintntl"
26. "zihintpause"
27. "zihpm"
28. "zimop"
29. "ztso"
Of which, 20 of them (29 minus 9 "no-RT" target features) support
runtime detection through `std::arch::is_riscv_feature_detected!()`.
cg_llvm: Replace some DIBuilder wrappers with LLVM-C API bindings (part 3)
- Part of rust-lang/rust#134001
- Follow-up to rust-lang/rust#136375
- Follow-up to rust-lang/rust#136632
---
This is another batch of LLVMDIBuilder binding migrations, replacing some our own LLVMRust bindings with bindings to upstream LLVM-C APIs.
This PR migrates all of the bindings that were touched by rust-lang/rust#136632, plus `LLVMDIBuilderCreateStructType`.
tests/run-make: Update list of statically linked musl targets
All of the tier 3 targets in the list now link dynamically by default (except `mips64el-unknown-linux-muslabi64`, I apparently overlooked that one in my PR that changed this).
Adjust the list of targets expected to link statically accordingly.
See also https://github.com/rust-lang/rust/pull/144410, which changed these targets.
Target by target:
- `mips64-unknown-linux-musl`: this target does not exist AFAICT
- `mips64-unknown-linux-muslabi64`: updated in the linked PR
- `powerpc-unknown-linux-musl`: updated in the linked PR
- `powerpc-unknown-linux-muslspe`: updated in the linked PR
- `powerpc64-unknown-linux-musl`: updated in the linked PR
- `riscv32gc-unknown-linux-musl`: updated in the linked PR
- `s390x-unknown-linux-musl`: updated in the linked PR
- `thumbv7neon-unknown-linux-musleabihf`: updated in the linked PR
Detect attempt to use var-args in closure
```
error: unexpected `...`
--> $DIR/no-closure.rs:11:14
|
LL | let f = |...| {};
| ^^^ not a valid pattern
|
= note: only `extern "C"` and `extern "C-unwind"` functions may have a C variable argument list
error: unexpected `...`
--> $DIR/no-closure.rs:16:17
|
LL | let f = |_: ...| {};
| ^^^
|
= note: only `extern "C"` and `extern "C-unwind"` functions may have a C variable argument list
```
Fixrust-lang/rust#146489, when trying to use c-style var-args in a closure. We emit a more targeted message. We also silence inference errors when the pattern is `PatKind::Err`.
Remove Rvalue::Len again.
Now that we have `RawPtrKind::FakeForPtrMetadata`, we can reimplement `Rvalue::Len` using `PtrMetadata(&raw const (fake) place)`.
r? ``@scottmcm``
StateTransform: Do not renumber resume local.
MIR parameters are not explicitly assigned-to when entering the MIR body. If we want to save their values inside the coroutine state, we need to do so explicitly.
This was done by renaming the `_2` local, and introducing an explicit assignment pre-transform. This particular trick confuses me.
This version makes explicit that we are assigning parameters to saved locals.
r? ``@dingxiangfei2009``
Add tidy readme
This PR adds a Readme to `src/tools/tidy`. Basically just explains how `tidy` works and covers all of tidy's checks, directives, and how to use tidy. I tried to add a bit more detail on some of the options like `--extra-checks` and the style directives that aren't really documented well elsewhere.
Planning to link to this in the dev guide.
Closes: rust-lang/rust#129368
don't apply temporary lifetime extension rules to non-extended `super let`
Reference PR: rust-lang/reference#1980
This changes the semantics for `super let` (and macros implemented in terms of it, such as `pin!`, `format_args!`, `write!`, and `println!`) as suggested by ````@theemathas```` in https://github.com/rust-lang/rust/issues/145784#issuecomment-3218658335, making `super let` initializers only count as [extending expressions](https://doc.rust-lang.org/nightly/reference/destructors.html#extending-based-on-expressions) when the `super let` itself is within an extending block. Since `super let` initializers aren't temporary drop scopes, their temporaries outside of inner temporary scopes are effectively always extended, even when not in extending positions; this only affects two cases as far as I can tell:
- Block tail expressions in Rust 2024. This PR makes `f(pin!({ &temp() }))` drop `temp()` at the end of the block in Rust 2024, whereas previously it would live until after the call to `f` because syntactically the `temp()` was in an extending position as a result of `super let` in `pin!`'s expansion.
- `super let` nested within a non-extended `super let` is no longer extended. i.e. a normal `let` is required to treat `super let`s as extending (in which case nested `super let`s will also be extending).
Closesrust-lang/rust#145784
This is a breaking change. Both static and dynamic semantics are affected. The most likely breakage is for programs to stop compiling, but it's technically possible for drop order to silently change as well (as in rust-lang/rust#145784). Since this affects stable macros, it probably would need a crater run.
Nominating for discussion alongside rust-lang/rust#145784: ````@rustbot```` label +I-lang-nominated +I-libs-api-nominated
Tracking issue for `super let`: rust-lang/rust#139076
initial implementation of the darwin_objc unstable feature
Tracking issue: https://github.com/rust-lang/rust/issues/145496
This feature makes it possible to reference Objective-C classes and selectors using the same ABI used by native Objective-C on Apple/Darwin platforms. Without it, Rust code interacting with Objective-C must resort to loading classes and selectors using costly string-based lookups at runtime. With it, these references can be loaded efficiently at dynamic load time.
r? ```@tmandry```
try-job: `*apple*`
try-job: `x86_64-gnu-nopt`
Update the minimum external LLVM to 20
With this change, we'll have stable support for LLVM 20 and 21.
For reference, the previous increase to LLVM 19 was rust-lang/rust#139275.
cc ```@rust-lang/wg-llvm```
r? nikic
Stabilize `btree_entry_insert` feature
This stabilises `btree_map::VacantEntry::insert_entry` and `btree_map::Entry::insert_entry`, following the FCP in [tracking issue](https://github.com/rust-lang/rust/issues/65225).
New stable API:
```rust
impl<'a, K: Ord, V, A: Allocator + Clone> Entry<'a, K, V, A> {
pub fn insert_entry(self, value: V) -> OccupiedEntry<'a, K, V, A>;
}
impl<'a, K: Ord, V, A: Allocator + Clone> VacantEntry<'a, K, V, A> {
pub fn insert_entry(mut self, value: V) -> OccupiedEntry<'a, K, V, A>;
}
```
(FCP ended almost a year ago, so if it's needed for process we could rerun it)
Closes: https://github.com/rust-lang/rust/issues/65225
libtest: expose --fail-fast as an unstable command-line option
This exposes the `fail_fast` option added in rust-lang/rust#105153 on the test harness command line, so that workflows that only want to know if any test fails can find out without waiting for everything to run. For example, cargo-mutants just needs to know if any tests fails. It only works with `-Zunstable-options`.
Tracking issue: rust-lang/rust#142859
Update cargo submodule
19 commits in 24bb93c388fb8c211a37986539f24a819dc669d3..966f94733bbc94ca51ff9f1e4c49ad250ebbdc50
2025-09-10 23:16:07 +0000 to 2025-09-16 17:24:45 +0000
- fix(frontmatter): Improve error quality (rust-lang/cargo#15972)
- fix: wrong variable name in documentation (rust-lang/cargo#15968)
- Add "Optimizing Build Performance" section to the Cargo book (rust-lang/cargo#15924)
- Remove extra apostrophe in environment-variables.md (rust-lang/cargo#15963)
- Clarify warning for using `features` or `default-features` in `patch` (rust-lang/cargo#15953)
- fix(frontmatter): Try alternative len code fences (rust-lang/cargo#15952)
- feat(cli): Allow completions for third-party subcommand names (rust-lang/cargo#15961)
- docs(index): Clarify what we mean by omitting features (rust-lang/cargo#15957)
- fix(future): Report all content as a single Report (rust-lang/cargo#15943)
- fix(complete): Show local crates/features over other members (rust-lang/cargo#15956)
- docs(resolver): Describe the role of the lockfile (rust-lang/cargo#15958)
- chore: Skip check-version-bump ci job in forks (rust-lang/cargo#15959)
- Eliminate the last three "did you mean" warning phrasings (rust-lang/cargo#15356)
- fix(info): Suggest a more universal `cargo tree` command (rust-lang/cargo#15954)
- feat(cli): Use ellipses when truncating progress (rust-lang/cargo#15955)
- feat(completer): Added completion for `--features` flag (rust-lang/cargo#15309)
- fix(publish): Switch the 'ctrl-c on wait' line to a help message (rust-lang/cargo#15942)
- docs: move docs building process to contributor guide (rust-lang/cargo#15854)
- fix(manifest): Show error source to users (rust-lang/cargo#15939)
r? ghost
Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#146442 (Display ?Sized, const, and lifetime parameters in trait item suggestions across a crate boundary)
- rust-lang/rust#146474 (Improve `core::ascii` coverage)
- rust-lang/rust#146605 (Bump rustfix 0.8.1 -> 0.8.7)
- rust-lang/rust#146611 (bootstrap: emit hint if a config key is used in the wrong section)
- rust-lang/rust#146618 (Do not run ui test if options specific to LLVM are used when another codegen backend is used)
r? `@ghost`
`@rustbot` modify labels: rollup
Keep space if arg does not follow punctuation when lint unused parens
Fixesrust-lang/rust#138234
If the arg follows punctuation, still pass `left_pos` with `None` and no space will be added, else then pass `left_pos` with `Some(arg.span.lo())`, so that we can add the space as expected.
And `emit_unused_delims` can make sure no more space will be added if the expr follows space.
---
Edited:
Directly use the `value_span` to check whether the expr removed parens will follow identifier or be followed by identifier.
Do not run ui test if options specific to LLVM are used when another codegen backend is used
Based on errors in https://github.com/rust-lang/rust/pull/146414, some tests with LLVM-specific options are run when another codegen is actually the one used.
This PR ignores these tests in such cases now to prevent this situation.
r? `@kobzol`
bootstrap: emit hint if a config key is used in the wrong section
based on discussion on rust-lang/rust#146591
now, if the user puts `build.download-rustc` in `bootstrap.toml`, they'll get a diagnostic:
``hint: try moving `download-rustc` to the `rust` section``
and if they nest things too much (`rust.rust.download-rustc`):
``hint: section name `rust` used as a key within a section``
if they specify a top-level key within a section (`rust.profile`):
``hint: try using `profile` as a top level key``
r? `@Kobzol`
Bump rustfix 0.8.1 -> 0.8.7
This commit can be replicated by running `cargo update -p rustfix --precise 0.8.7 && x test ui --bless`.
---
The reasons this affects UI tests is as follows:
- The UI test suite runs rustc with `-Z deduplicate-diagnostics=no --error-format=json`, which means that rustc emits multiple errors containing identical suggestions. That caused the weird-looking code that had multiple `X: Copy` suggestions.
- Those suggestions are interpreted not by rustc itself, but by the `rustfix` library, maintained by cargo but published as a separate crates.io library and used by compiletest.
- Sometime between rustfix 0.8.1 and 0.8.7 (probably in rust-lang/cargo#14747, but it's hard to tell because rustfix's versioning doesn't match cargo's), rustfix got smarter and stopped applying duplicate suggestions.
Update rustfix to match cargo's behavior. Ideally, we would always share a version of rustfix between cargo and rustc (perhaps with a path dependency?), to make sure we are testing the behavior we ship. But for now, just manually update it to match.
Note that the latest version of rustfix published to crates.io is 0.9.1, not 0.8.7. But 0.9.1 is not the version used in cargo, which is 0.9.3. Rather than trying to match versions exactly, I just updated rustfix to the latest in the 0.8 branch.
Display ?Sized, const, and lifetime parameters in trait item suggestions across a crate boundary
context: rust-lang/rust#145929
This fixes the MetaSized issue and adds const generics and early bound lifetimes. Late bound lifetimes are harder because they aren't returned by `generics_of`. I'm going to look into it, but there's no guarantee I'll be successful.
Fixes https://github.com/rust-lang/rust/issues/146404.
r? `@BoxyUwu`
When writing something like the expression `|_: ...| {}`, we now detect the `...` during parsing explicitly instead of relying on the detection in `parse_ty_common` so that we don't talk about "nested `...` are not supported".
```
error: unexpected `...`
--> $DIR/no-closure.rs:6:35
|
LL | const F: extern "C" fn(...) = |_: ...| {};
| ^^^
|
= note: only `extern "C"` and `extern "C-unwind"` functions may have a C variable argument list
```
Tsukasa OI