Merge `associated_const_equality` feature gate into MGCA
Tracking Issues: rust-lang/rust#132980rust-lang/rust#92827
Merge `associated_const_equality`(ACE) feature gate into `min_generic_const_args`(MGCA).
- Replaces `features().associated_const_equality()` checks with `features().min_generic_const_args()`
- Updates the parser to gate associated const equality under `min_generic_const_args`
- Moves `associated_const_equality` to the removed features list
- Removes the `associated_const_equality` method from the `Features` trait
- Updates all affected tests and tools (rust-analyzer, clippy)
Closesrust-lang/rust#150617
r? `@BoxyUwU`
This removes `associated_const_equality` as a separate feature gate and makes it part of `min_generic_const_args` (mgca).
Key changes:
- Remove `associated_const_equality` from unstable features, add to removed
- Update all test files to use `min_generic_const_args` instead
- Preserve the original "associated const equality is incomplete" error message by specially handling `sym::associated_const_equality` spans in `feature_gate.rs`
- Rename FIXME(associated_const_equality) to FIXME(mgca)
Add checks for gpu-kernel calling conv
The `gpu-kernel` calling convention has several restrictions that were not enforced by the compiler until now.
Add the following restrictions:
1. Cannot be async
2. Cannot be called
3. Cannot return values, return type must be `()` or `!`
4. Arguments should be simple, i.e. passed by value. More complicated types can work when you know what you are doing, but it is rather unintuitive, one needs to know ABI/compiler internals.
5. Export name should be unmangled, either through `no_mangle` or `export_name`. Kernels are searched by name on the CPU side, having a mangled name makes it hard to find and probably almost always unintentional.
Tracking issue: rust-lang/rust#135467
amdgpu target tracking issue: rust-lang/rust#135024
``@workingjubilee,`` these should be all the restrictions we talked about a year ago.
cc ``@RDambrosio016`` ``@kjetilkjeka`` for nvptx
The `gpu-kernel` calling convention has several restrictions that were
not enforced by the compiler until now.
Add the following restrictions:
1. Cannot be async
2. Cannot be called
3. Cannot return values, return type must be `()` or `!`
4. Arguments should be primitives, i.e. passed by value. More complicated
types can work when you know what you are doing, but it is rather
unintuitive, one needs to know ABI/compiler internals.
5. Export name should be unmangled, either through `no_mangle` or
`export_name`. Kernels are searched by name on the CPU side, having
a mangled name makes it hard to find and probably almost always
unintentional.
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>
Externally implementable items
Supersedes https://github.com/rust-lang/rust/pull/140010
Tracking issue: https://github.com/rust-lang/rust/issues/125418
Getting started:
```rust
#![feature(eii)]
#[eii(eii1)]
pub fn decl1(x: u64)
// body optional (it's the default)
{
println!("default {x}");
}
// in another crate, maybe
#[eii1]
pub fn decl2(x: u64) {
println!("explicit {x}");
}
fn main() {
decl1(4);
}
```
- tiny perf regression, underlying issue makes multiple things in the compiler slow, not just EII, planning to solve those separately.
- No codegen_gcc support, they don't have bindings for weak symbols yet but could
- No windows support yet for weak definitions
This PR merges the implementation of EII for just llvm + not windows, doesn't yet contain like a new panic handler implementation or alloc handler. With this implementation, it would support implementing the panic handler in terms of EII already since it requires no default implementation so no weak symbols
The PR has been open in various forms for about a year now, but I feel that having some implementation merged to build upon
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.
Add a warn-by-default `unused_visibility` lint for visibility qualifiers
on `const _` declarations - e.g. `pub const _: () = ();`.
These have no effect.
Move attribute safety checking to attribute parsing
This PR moves attribute safety checking to be done during attribute parsing. The `cfg` and `cfg_attr` attribute no longer need special-cased safety checking, yay!
This PR is a part 1 of 2, in the second part I'd like to define attribute safety in the attribute parsers rather than getting the information from BUILTIN_ATTRIBUTE_MAP, but to keep PRs reviewable lets do that separately.
Fixes https://github.com/rust-lang/rust/issues/148453 by reordering the diagnostics. The "cannot find attribute" diagnostic now appears first, but both diagnostics still appear.
r? `@jdonszelmann`
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```
mgca: Add ConstArg representation for const items
tracking issue: rust-lang/rust#132980fixesrust-lang/rust#131046fixesrust-lang/rust#134641
As part of implementing `min_generic_const_args`, we need to distinguish const items that can be used in the type system, such as in associated const equality projections, from const items containing arbitrary const code, which must be kept out of the type system. Specifically, all "type consts" must be either concrete (no generics) or generic with a trivial expression like `N` or a path to another type const item.
To syntactically distinguish these cases, we require, for now at least, that users annotate all type consts with the `#[type_const]` attribute. Then, we validate that the const's right-hand side is indeed eligible to be a type const and represent it differently in the HIR.
We accomplish this representation using a new `ConstItemRhs` enum in the HIR, and a similar but simpler enum in the AST. When `#[type_const]` is **not** applied to a const (e.g. on stable), we represent const item right-hand sides (rhs's) as HIR bodies, like before. However, when the attribute is applied, we instead lower to a `hir::ConstArg`. This syntactically distinguishes between trivial const args (paths) and arbitrary expressions, which are represented using `AnonConst`s. Then in `generics_of`, we can take advantage of the existing machinery to bar the `AnonConst` rhs's from using parent generics.
c-variadic: allow c-variadic inherent and trait methods
tracking issue: https://github.com/rust-lang/rust/issues/44930
Continuing the work of https://github.com/rust-lang/rust/pull/146342, allow inherent and trait methods to be c-variadic. However, a trait that contains a c-variadic method is no longer dyn-compatible.
There is, presumably, some way to make c-variadic methods dyn-compatible. However currently, we don't have confidence that it'll work reliably: when methods from a `dyn` object are cast to a function pointer, a `ReifyShim` is created. If that shim is c-variadic, it would need to forward the C variable argument list.
That does appear to work, because the `va_list` is not represented in MIR at all in this case, so the registers from the call site are untouched by the shim and can be read by the actual implementation. That just does not seem like a solid implementation.
Also, intuitively, why would c-variadic function, primarily needed for FFI, need to be used with `dyn` objects at all? We can revisit this limitation if a need arises.
r? `@workingjubilee`
but a C-variadic method makes a trait dyn-incompatible. That is because
methods from dyn traits, when cast to a function pointer, create a shim.
That shim can't really forward the c-variadic arguments.
