lib: specialize Clone of array IntoIter
This PR adds the `TrivialClone` specialization to the `PolymorphicIter` type, which `array::IntoIter` uses. I also added another coretest for the default case (already existing test catches the specialized one).
There are no unwinding concerns since `TrivialClone` means cloning = copying and we never call `Clone::clone`.
`array:IntoIter` is being used on a lot of places in both `core` and in user code, and `array::IntoIter` (nor does its users) override `Clone` often and just delegate to the inner type `PolymorphicIter` which does not yet do the `TrivialClone` specialization and is burdened by the iterator and unwind safety shenanigans for all types, so this PR should address some of that. This should in turn slightly reduce both stack usage and remove unwinding prologue/epilogue etc. from such functions and improve our `-Cno-prepopulate-passes` codegen too.
perf: https://godbolt.org/z/eTPjj3hP3
Reject invalid codegen backends on CI
The way we set codegen backends in CI jobs contained several bugs.
1) We didn't check if the specified codegen backend is valid. That can be useful in forks, but not on our CI, there it should be a loud error.
2) The codegen backends were specified with weird quoting that was (I think) producing invalid backends.
3) The specified backends in `RUST_CONFIGURE_ARGS` were being overridden due to `run.sh` setting codegen backends based on the `CODEGEN_BACKENDS` environment variable (see https://github.com/rust-lang/rust/pull/156989).
This PR should fix all of these.
After doing some CI runs on this PR, I realized that setting `CODEGEN_BACKENDS` from within the Dockerfile doesn't work, because we use `docker run --env CODEGEN_BACKENDS`, and that will unset the inner env even if the same env is not actually configured in the environment from where `docker run` is executed (sigh). So instead I decided to pass the env variables from `jobs.yml`. It's not really pretty, but it is a solution that should work with the current structure.
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#157046 (file locking: clarify that double-locking is underspecified)
- rust-lang/rust#156401 (rustdoc: deterministic sorting for `doc_cfg` badges)
- rust-lang/rust#156746 (cg_llvm: Use `LLVMDIBuilderCreateEnumeratorOfArbitraryPrecision`)
- rust-lang/rust#156889 (Suggest function-local constructors without enclosing function path)
- rust-lang/rust#157012 (Fix missing note of escaping `{` for braces including whitespaces)
- rust-lang/rust#157056 (Update Xtensa target data layouts to match upstream LLVM)
- rust-lang/rust#157062 (Add link to RFMF Sponsors page)
Update Xtensa target data layouts to match upstream LLVM
Born from https://github.com/rust-lang/rust/pull/156568#issuecomment-4563228595.
We've been using a fork to distribute compiler builds that support the Xtensa arch whilst we're upstreaming. At a certain point we received some changes on our fork, which haven't been upstreamed, which I now to believe to be a mistake - therefore I'm reverting to the upstream LLVM datalayout.
r? @folkertdev
Suggest function-local constructors without enclosing function path
Closesrust-lang/rust#144319
This fixes a mismatched-type wrapper suggestion for constructors defined inside
function-like scopes. The previous diagnostic used `def_path_str` directly, so a
function-local tuple struct could be suggested as `main::Foo(false)`, even though
`main` is not a module path that can name the constructor.
The suggestion now prints the constructor path under rustc's existing suggestion
printer mode. That mode omits path segments that cannot be written in source,
while preserving real path segments such as local modules and enum names.
The regression test covers:
- a function-local tuple struct constructor
- a function-local enum variant
- a tuple struct inside a function-local module
- a tuple struct inside a closure body
- a tuple struct inside an inline const block
cg_llvm: Use `LLVMDIBuilderCreateEnumeratorOfArbitraryPrecision`
- Part of https://github.com/rust-lang/rust/issues/134001
- Follow-up to https://github.com/rust-lang/rust/pull/146763
---
This PR replaces our custom `LLVMRustDIBuilderCreateEnumerator` FFI binding with an equivalent LLVM-C binding to `LLVMDIBuilderCreateEnumeratorOfArbitraryPrecision`, which was introduced in LLVM 21.
I have also added comments to the remaining `LLVMRustDIBuilder` functions explaining why they currently can't use an LLVM-C binding, and noted some other functions that can use LLVM-C bindings in the future.
rustdoc: deterministic sorting for `doc_cfg` badges
Fixesrust-lang/rust#156391
Currently, target-exclusive `doc_cfg` badges (eg. "Available on...") reuse the order of predicates as they appear in the source code. This often buries popular targets behind niche ones and leads to inconsistent UI rendering.
This PR introduces a deterministic sorting mechanism to the `Cfg` AST prior to HTML/JSON rendering.
**Note for Reviewers:**
To provide the best UX, I implemented a lightweight tiering heuristic (prioritizing major platforms like Linux/Apple/Windows first, followed by mobile, then BSDs, and alphabetizing the rest). However, I am completely open to tweaking these priority groupings or falling back to a different sorting logic if the team prefers. Let me know what you think!
Offload: Update confusing and outdated file name
We swapped the order in which we do host and device compilations. The file getting renamed is effectively the output of the clang-offload-packager, the first magic bytes (`00000000 10 ff 10 ad`) confirm it. I was just creating a figure to visualize and noticed that the name is off.
cc @Kevinsala @jdoerfert is there any naming convention?
r? oli-obk
coverage: Build the expansion tree around `SyntaxContext`
The expansion tree was previously built around `ExpnId`, which was subtly incorrect in cases where multiple distinct syntax contexts share the same `outer_expn` ID. This can occur in the presence of nested macro expansions.
This change turns out to be fairly straightforward, because in all cases we were obtaining `ExpnId` from `span.ctxt().outer_expn()` anyway, so we can just remove the call to `.outer_expn()` and use the context instead.
As a result of this change, `context-mismatch-issue-147339.rs` no longer triggers a context mismatch in `extract_refined_covspans`, so this PR is a more principled fix for https://github.com/rust-lang/rust/issues/147339.
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#156932 (relnotes for 1.96)
- rust-lang/rust#156403 (Add `TypeId` methods `variants` `fields` `field` for `type_info`)
- rust-lang/rust#156797 (Suggest adding quotation marks to identifiers in attributes)
- rust-lang/rust#157014 (Allow building the source tarballs while offline)
- rust-lang/rust#157023 (`#[expect]` is an attribute valid for outer style)
- rust-lang/rust#157025 (Show crate root path in misplaced crate-level attribute diagnostic)
Show crate root path in misplaced crate-level attribute diagnostic
Fixesrust-lang/rust#157001
If you put `#![feature(...)]` inside a non-root module, the diagnostic tells you it can only be used at the crate root, but never says where the crate root actually is. Not great if you're new to Rust or working in a big workspace with nested modules.
Now the diagnostic includes a help line with the crate root file path when the misplaced attribute is an inner attribute. Outer attributes already get a span note pointing at what they're applied to, so they don't need this. Path goes through `RemapPathScopeComponents::DIAGNOSTICS` so `--remap-path-prefix` is respected.
```
warning: the `#![feature]` attribute can only be used at the crate root
--> src/foo.rs:1:1
|
LL | #![feature(test)]
| ^^^^^^^^^^^^^^^^^
|
= help: the crate root is at `src/main.rs`
```
Allow building the source tarballs while offline
Previously locally vendored dependencies wouldn't be reused when building the source tarball, instead everything would be downloaded from the internet again (if not in the cargo cache).
Fixes https://github.com/rust-lang/rust/issues/156982
Suggest adding quotation marks to identifiers in attributes
When the user provides an identifier when a literal was expected in an attribute value, suggest adding quotation marks to the identifier to make it a string literal.
For instance:
```
error: attribute value must be a literal
--> $DIR/crate-type-non-crate.rs:9:16
|
LL | #[crate_type = lib]
| ^^^ help: try adding quotation marks: `"lib"`
```
Add `TypeId` methods `variants` `fields` `field` for `type_info`
Tracking issue rust-lang/rust#146922
- Adds `fn TypeId::variants` returns the number of variants, for struct and union and primitive types, it's always 1.
- Adds `fn TypeId::fields` returns the number of fields.
- Adds `fn TypeId::field` returns a field representing type `FieldId`.
- Adds a new type `FieldId`, which is a wrapper of `FieldRepresentingType`'s `TypeId`.
For methods `{fields,field}`, if indexing out of bounds, a compile-time error will be raised.
Regarding the removal of `Type` items, this will be done in a later PR in one go.
r? @oli-obk
The expansion tree was previously built around `ExpnId`, which was subtly
incorrect in cases where multiple distinct syntax contexts share the same
`outer_expn` ID. This can occur in the presence of nested macro expansions.
This change turns out to be fairly straightforward, because in all cases we
were obtaining `ExpnId` from `span.ctxt().outer_expn()` anyway, so we can just
remove the call to `.outer_expn()` and use the context instead.
As a result of this change, `context-mismatch-issue-147339.rs` no longer
triggers a context mismatch in `extract_refined_covspans`.
Place submod.rs under tests/ui/attributes/auxiliary/ and use
#[path] to include it, matching the preferred compiletest
test structure. Removes the need for //@ ignore-auxiliary.
Rollup of 10 pull requests
Successful merges:
- rust-lang/rust#156970 (coverage: Use original HIR info for synthetic by-move coroutine bodies)
- rust-lang/rust#157022 (MIR inlining: allow backends to opt-in to inlining intrinsics)
- rust-lang/rust#157026 (miri subtree update)
- rust-lang/rust#156390 (Constify Iterator-related methods and functions)
- rust-lang/rust#156845 (Clarify "infinite size" in cyclic-type diagnostic refers to the type name)
- rust-lang/rust#156955 (Fix const-eval of shared generic reborrows)
- rust-lang/rust#156973 (Add uwtable annotation to modules when required)
- rust-lang/rust#156985 (Limit the additional DLL to Windows)
- rust-lang/rust#156988 (interpret/validity: properly treat zero-variant enums so that we do not have to check layout.is_uninhabited)
- rust-lang/rust#157002 (std: Fix thread::available_parallelism on Redox targets)
interpret/validity: properly treat zero-variant enums so that we do not have to check layout.is_uninhabited
I am very happy to finally remove the last of these somewhat ad-hoc checks. :)
r? @oli-obk
Add uwtable annotation to modules when required
When unwind tables are enabled with `-Cforce-unwind-tables=y`, Rust will annotate all functions with the `uwtable` annotation. However, this annotation is missing on modules, which leads to incorrect unwind tables being generated by LLVM for constructors (such as `asan.module_ctor`).
This was discovered because it leads to a crash in Linux when KASAN and dynamic shadow call stack are both enabled. In this scenario, the kernel uses the unwind tables to locate the `paciasp` and `autiasp` instructions in each function and patches the machine code at boot to use the shadow call stack instructions instead. However, LLVM's AArch64PointerAuth pass emits DWARF info for `paciasp` whenever `-g` is passed, but only emits DWARF info for `autiasp` when the `uwtable` attribute is present. Since the `uwtable` annotation is missing for modules, the relevant directives are generated for only the `autiasp` instruction in `asan.module_ctor`, and not for the `paciasp` instruction. This causes the kernel's dynamic SCS logic to patch the prolouge of `asan.module_ctor`, but not the epilogue. This leads to a crash as the shadow call stack becomes unbalanced.
The fact that LLVM doesn't use the same condition for whether to emit DWARF information for both instructions may be a separate bug in LLVM.
Relevant issue: https://github.com/llvm/llvm-project/issues/188234
AI assistance was used to determine the root cause of this crash from the observed symptoms, and to write the tests. Also thanks to @samitolvanen and @maurer for debugging this issue.
Similar to this previous PR of mine: rust-lang/rust#130824
Fix const-eval of shared generic reborrows
`Rvalue::Reborrow` const-eval now handles shared generic reborrows produced by `CoerceShared`. Those reborrows intentionally copy from the source ADT into a distinct same-layout target ADT, so the interpreter uses the transmute-capable copy path for `Mutability::Not`.
Promotion is intentionally kept conservative: promotion candidates whose validated temporary graph contains `Rvalue::Reborrow` are rejected, so generic/user-defined reborrows are not promoted.
Fixesrust-lang/rust#156313.
cc @aapoalas
Tracking: rust-lang/rust#145612
@rustbot label F-reborrow
Clarify "infinite size" in cyclic-type diagnostic refers to the type name
Closesrust-lang/rust#149842
The `TypeError::CyclicTy` diagnostic currently emits
"cyclic type of infinite size". As discussed in the issue, "infinite
size" reads as the in-memory `size_of::<T>()` of values, when it
actually refers to the textual representation of the type name (an
iso-recursive occurs-check failure).
This rewords the message so the qualifier "infinite-size" clearly
modifies the *name*, matching the direction `@fmease`, `@BoxyUwU`,
and the issue author converged on:
```
- cyclic type of infinite size
+ recursive type with infinite-size name
```
Nine existing UI `.stderr` baselines and two `//~ NOTE` annotations
are updated to track the new wording. No semantics change.
Tested:
- ./x test tests/ui/const-generics/occurs-check/ tests/ui/closures/ tests/ui/unboxed-closures/ tests/ui/typeck/ tests/ui/coroutine/ --force-rerun
- ./x test tidy
bors