Move shared offload globals and define per-kernel globals once
This PR moves the shared LLVM global variables logic out of the `offload` intrinsic codegen and generates kernel-specific variables only ont he first call of the intrinsic.
r? `@ZuseZ4`
tracking:
- https://github.com/rust-lang/rust/issues/131513
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>
148725 moved the default to being homogeneous; this adds heterogeneous ones back under an obvious-bikeshed syntax so people can experiment with that as well.
Essentially resolves 149025 by letting them move to this syntax instead.
Stabilize `asm_cfg`
tracking issue: https://github.com/rust-lang/rust/issues/140364
closes https://github.com/rust-lang/rust/issues/140364
Reference PR:
- https://github.com/rust-lang/reference/pull/2063
# Request for Stabilization
## Summary
The `cfg_asm` feature allows `#[cfg(...)]` and `#[cfg_attr(...)]` on the arguments of the assembly macros, for instance:
```rust
asm!( // or global_asm! or naked_asm!
"nop",
#[cfg(target_feature = "sse2")]
"nop",
// ...
#[cfg(target_feature = "sse2")]
a = const 123, // only used on sse2
);
```
## Semantics
Templates, operands, `options` and `clobber_abi` in the assembly macros (`asm!`, `naked_asm!` and `global_asm!`) can be annotated with `#[cfg(...)]` and `#[cfg_attr(...)]`. When the condition evaluates to true, the annotated argument has no effect, and is completely ignored when expanding the assembly macro.
## Documentation
reference PR: https://github.com/rust-lang/reference/pull/2063
## Tests
- [tests/ui/asm/cfg.rs](https://github.com/rust-lang/rust/blob/master/tests/ui/asm/cfg.rs) checks that `cfg`'d arguments where the condition evaluates to false have no effect
- [tests/ui/asm/cfg-parse-error.rs](https://github.com/rust-lang/rust/blob/master/tests/ui/asm/cfg.rs) checks the parsing rules (parsing effectively assumes that the cfg conditions are all true)
## History
- https://github.com/rust-lang/rust/issues/140279
- https://github.com/rust-lang/rust/pull/140367
# Resolved questions
**how are other attributes handled**
Other attributes are parsed, but explicitly rejected.
# unresolved questions
**operand before template**
The current implementation expects at least one template string before any operands. In the example below, if the `cfg` condition evaluates to true, the assembly block is ill-formed. But even when it evaluates to `false` this block is rejected, because the parser still expects just a template (a template is parsed as an expression and then validated to ensure that it is or expands to a string literal).
Changing how this works is difficult.
```rust
// This is rejected because `a = out(reg) x` does not parse as an expresion.
asm!(
#[cfg(false)]
a = out(reg) x, //~ ERROR expected token: `,`
"",
);
```
**lint on positional arguments?**
Adding a lint to warn on the definition or use of positional arguments being `cfg`'d out was discussed in https://github.com/rust-lang/rust/issues/140279#issuecomment-2832237372 and subsequent comments. Such a lint is not currently implemented, but that may not be a blocker based on the comments there.
r? `@traviscross` (I'm assuming you'll reassign as needed)
Remove `#[const_trait]`
Remove `#[const_trait]` since we now have `const trait`. Update all structured diagnostics that still suggested the attribute.
r? ```@rust-lang/project-const-traits```
Encode cfg trace, not its early counterpart to fix cross-crate `doc(auto_cfg)`
Fixesrust-lang/rust#141301.
<details><summary>Rambling about <code>target_feature</code> which I didn't touch here</summary>
Regarding https://github.com/rust-lang/rust/issues/141301#issuecomment-3390100259 (`#[target_feature(enable = …)]` on inlined cross-crate re-exports), it has the same underlying cause (namely, we neither encode `target_feature` nor `AttributeKind::TargetFeature` in the crate metadata). However, I didn't make that change because I first want to experiment with querying `TyCtxt::codegen_fn_attrs` in rustdoc instead which already works cross-crate (and also use to it for reconstructing `no_mangle`, `export_name`, `link_section` to avoid encoding these attributes unnecessarily (basically reverting rust-lang/rust#144050) as suggested in https://github.com/rust-lang/rust/issues/144004#issuecomment-3077725837).
</details>
r? GuillaumeGomez
Add an attribute to check the number of lanes in a SIMD vector after monomorphization
Allows std::simd to drop the `LaneCount<N>: SupportedLaneCount` trait and maintain good error messages.
Also, extends rust-lang/rust#145967 by including spans in layout errors for all ADTs.
r? ``@RalfJung``
cc ``@workingjubilee`` ``@programmerjake``
We need a different attribute than `rustc_align` because unstable attributes are
tied to their feature (we can't have two unstable features use the same
unstable attribute). Otherwise this uses all of the same infrastructure
as `#[rustc_align]`.
Allow `inline(always)` with a target feature behind a unstable feature `target_feature_inline_always`.
Rather than adding the inline always attribute to the function definition, we add it to the callsite. We can then check that the target features match and that the call would be safe to inline. If the function isn't inlined due to a mismatch, we emit a warning informing the user that the function can't be inlined due to the target feature mismatch.
See tracking issue rust-lang/rust#145574
bors