Port #[no_link] to use attribute parser
Adds `#[no_link]` to the attribute parser, as well as adds tests making sure to FCW warn on `field`, `arm`, and `macrodef `
Partially revert #147888 and print warning if LLVM CMake dir is missing when building Enzyme
Partially reverts https://github.com/rust-lang/rust/pull/147888, Enzyme cannot be build with `download-ci-llvm = true`.
r? ``@ZuseZ4``
autodiff: emit an error if we fail to find libEnzyme
Tested manually by moving libEnzyme-21.so away. We should adjust the error msg. once we have the component up.
It's the first usage within rustc of this experimental feature, but afaik we're open to dogfooding those for test purpose, right?
r? ``@Kobzol``
Port `#[rustc_legacy_const_generics]` to use attribute parser
Small PR that ports the `#[rustc_legacy_const_generics]` to use the new attribute parser!
r? JonathanBrouwer
std: io: error: Add comment for UEFI unpacked repr use
The following commit adds the comment explaining the rational why UEFI uses unpacked representation on 64-bit platforms as opposed to bit-packed representation used in all other 64-bit platforms.
r? `@bjorn3`
Use annotate-snippet as default emitter on stable
This is implementation of https://github.com/rust-lang/rust/issues/149932
Now, after MCP was accepted, we can use annotate-snippet as default emitter for errors, that means that we not longer need of previous emitter, so this PR removed previous emitter and makes annotate-snippet new default one both on stable and nightly
(this PR does not remove a code of previous emitter it just removes a `Default` option of `HumanReadableErrorType` enum, and keeping only `HumanReadableErrorType::AnnotateSnippet` as it now uses by default)
dont create unnecessary `DefId`s under mgca
Fixesrust-lang/rust#149977Fixesrust-lang/rust#148838
Accidentally left this out of rust-lang/rust#149136 even though being able to do this was a large part of the point of the PR :3
First ICE was caused by the fact that we create a defid but never lower the nodeid associated with it to a hirid which later parts of the compiler can't handle.
See test for second ICE
r? oli-obk
custom `VaList` layout for Hexagon
I noticed while browsing LLVM source that we use an incorrect `VaList` definition for the musl hexagon target.
relevant links
- 0cdc1b6dd4/clang/include/clang/Basic/TargetInfo.h (L333)
- 0cdc1b6dd4/clang/lib/CodeGen/Targets/Hexagon.cpp (L407-L417)
cc target maintainer `@androm3da` can you confirm that this looks OK? In particular the `#[rustc_pass_indirectly_in_non_rustic_abis]` attribute is used to simulate pointer decay (like if the struct were wrapped in a 1-element array in C). The clang comment suggests that the Tag is wrapped in such a single-element array, but I haven't actually been able to confirm it.
For stabilizing `c_variadic` (on the hexagon targets) we will also need a custom `va_arg` implementation to mirror the one in `clang` in [va_arg.rs](https://github.com/rust-lang/rust/blob/main/compiler/rustc_codegen_llvm/src/va_arg.rs). Would you be able to contribute one?
r? `@workingjubilee`
Tidying up tests/ui/issues 33 tests [4/N]
> [!NOTE]
> Intermediate commits are intended to help review, but will be squashed add comment commit prior to merge.
part of rust-lang/rust#133895
`tests/ui/compile-flags` split it into `tests/ui/compile-flags/invalid/` and `tests/ui/compile-flags/run-pass/`
r? Kivooeo
The following commit adds the comment explaining the rational why UEFI
uses unpacked representation on 64-bit platforms as opposed to bit-packed
representation used in all other 64-bit platforms.
Signed-off-by: Ayush Singh <ayush@beagleboard.org>
Fix span note for question mark expression
Fixesrust-lang/rust#144304
Seems it's better to fix the note instead of modifying the span to cover the whole expression.
r? `@estebank`
`rustc_scalable_vector(N)`
Supercedes rust-lang/rust#118917.
Initial experimental implementation of rust-lang/rfcs#3838. Introduces a `rustc_scalable_vector(N)` attribute that can be applied to types with a single `[$ty]` field (for `u{16,32,64}`, `i{16,32,64}`, `f{32,64}`, `bool`). `rustc_scalable_vector` types are lowered to scalable vectors in the codegen backend.
As with any unstable feature, there will necessarily be follow-ups as we experiment and find cases that we've not considered or still need some logic to handle, but this aims to be a decent baseline to start from.
See rust-lang/rust#145052 for request for a lang experiment.
The `fmt::Debug` impl for `TyAndLayout<'a, Ty>'` requires `fmt::Display`
on the `Ty` parameter. In `ArgAbi`, `TyAndLayout`'s Ty` is instantiated
with a parameter that implements `TyAbiInterface`. `TyAbiInterface`
only required `fmt::Debug` be implemented on `Self`, not `fmt::Display`,
which meant that it wasn't actually possible to debug print `ArgAbi`.
LLVM doesn't handle stores on `<vscale x N x i1>` for `N != 16`, a type
used internally in SVE intrinsics. Spilling to the stack to create
debuginfo will cause errors during instruction selection. These types
that are an internal implementation detail to the intrinsic, so users
should never see them types and won't need any debuginfo.
Co-authored-by: Jamie Cunliffe <Jamie.Cunliffe@arm.com>
Introduces `BackendRepr::ScalableVector` corresponding to scalable
vector types annotated with `repr(scalable)` which lowers to a scalable
vector type in LLVM.
Co-authored-by: Jamie Cunliffe <Jamie.Cunliffe@arm.com>
Extend well-formedness checking and HIR analysis to prohibit the use of
scalable vectors in structs, enums, unions, tuples and arrays. LLVM does
not support scalable vectors being members of other types, so these
restrictions are necessary.
Co-authored-by: Jamie Cunliffe <Jamie.Cunliffe@arm.com>
Extend parsing of `ReprOptions` with `rustc_scalable_vector(N)` which
optionally accepts a single literal integral value - the base multiple of
lanes that are in a scalable vector. Can only be applied to structs.
Co-authored-by: Jamie Cunliffe <Jamie.Cunliffe@arm.com>
assert impossible branch is impossible
The second half of this boolean or expression should not be possible with the current visitation implementation.
Reasoning:
- Innermost res will always be the first candidate visited.
- the first scopes visited are `derive_helper` candidates, followed by a single step at `derive_helper_compat`: ee447067/compiler/rustc_resolve/src/ident.rs (L180-L192)
- if there are candidates for both kinds the derive_helper candidate will always be innermost
- there can only be one derive_helper_compat candidate
- The first branch handles cases where the first candidate is a `derive_helper_compat`
- if the first candidate is not a `derive_helper_compat` (as enforced by the first branch) and it is not a `derive_helper` (as enforced by the end of the second boolean expression) then then the first candidate and all subsequent candidates must be from later scope types, res cannot possibly be a `derive_helper_compat`
r? ``@petrochenkov``
Update books
## rust-lang/nomicon
1 commits in 9fe8fa599ad228dda74f240cc32b54bc5c1aa3e6..5b3a9d084cbc64e54da87e3eec7c7faae0e48ba9
2025-12-12 12:24:05 UTC to 2025-12-12 12:24:05 UTC
- Update method lookup link in dot-operator.md (rust-lang/nomicon#513)
## rust-lang/reference
4 commits in 50c5de90487b68d429a30cc9466dc8f5b410128f..ec78de0ffe2f8344bd0e222b17ac7a7d32dc7a26
2025-12-15 16:17:43 UTC to 2025-12-15 16:15:06 UTC
- tokens: clarify in escape tables that digits are hex (rust-lang/reference#2105)
- tokens: remove misplaced ".token." within a word (rust-lang/reference#2106)
- macros-by-example: add space in `macro.decl.repetition.fragment` example (rust-lang/reference#2107)
- Fix restrictions of or-patterns (rust-lang/reference#2108)
document that mpmc channels deliver an item to (at most) one receiver
Tiny documentation change related to mpmc (tracking issue rust-lang/rust#126840).
This PR is meant to supersede rust-lang/rust#140158 due to it's inactivity. It is essentially the same addition structured a little differently.
Metadata loader cleanups
Couple of cleanups I found while working on https://github.com/rust-lang/rust/pull/149273
This renames some fields and enum variants to clarify what they are used for, moves a check to another method and slightly simplifies the way profiler_builtins is linked.
Simplify how inline asm handles `MaybeUninit`
This is just better, but this is also allows it to handle changes from https://github.com/rust-lang/rust/pull/149614 (i.e. `ManuallyDrop` containing `MaybeDangle`).
