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
`reborrow_info` validates that all data fields of a struct implementing
`Reborrow` are either `Copy` or themselves `Reborrow`. When a field
implementing `Reborrow` was found, the loop returned `Ok(())` immediately,
so any remaining fields were never validated. This let a struct whose
first data field is `Reborrow` and whose second field is neither `Copy`
nor `Reborrow` incorrectly implement `Reborrow`.
Change the early `return Ok(())` to `continue` so every field is checked.
delegation: emit error when self type is not specified and accessed
This PR adds error reporting when we create error self type if it was not specified. In most of the tests there were other errors, so this delayed bug was not triggered, but there are cases like `reuse Default::default;` (rust-lang/rust#156388) which does not emit other errors and those delayed bugs are triggered.
Part of rust-lang/rust#118212. Fixesrust-lang/rust#156388.
r? @petrochenkov
When an unconstrained type or lifetime parameter is detected in an
`impl`, provide more specific help based on its usage:
- If the parameter is entirely unused, suggest removing it.
- If it is used in the `impl` body but not the `Self` type, suggest
including it in the `Self` type and the struct definition.
This also adds a comprehensive UI test for these cases.
Add `const_param_ty_unchecked` gate
Add `const_param_ty_unchecked` internal feature gate to skip `ConstParamTy_` trait enforcement on type. Provides an escape hatch for writing tests and examples that use const generics without needing to ensure all fields implement `ConstParamTy_`.
r? BoxyUwU
Remove unused spans from AttributeKind
Recently I noticed some spans in diagnostic attributes were never used. I went through and checked the other variants too.
Suggest `[const] Trait` bounds in more places
Right now we have some special logic in the const checker for emitting `[const] Trait` suggestions, but I'm trying to handle that similarly to how it is handled for normal `Trait` clauses. This is just a small step in how it will look on the UX side, which should make my follow-up PRs affect tests less and just be a refactoring
Change `ItemKind::Trait` to a field variant.
This changes `ItemKind::Trait` from an octuple(!!) to an enum variant with fields. Their names were chosen to match up with existing usage and minimize renaming.
I'm leaning towards renaming `ident` to `name` as well; let me know if that's desired.
* Implement core::arch::return_address and tests
Fix typo
Apply suggestions from code review
Wording/docs changes.
Co-authored-by: Ralf Jung <post@ralfj.de>
Change signature according to Ralf's comment
Fix call to `core::intrinsics::return_address()` according to the new signature
Add cranelift implementation for intrinsic
Change wording on `return_address!()` to be clear that returning a null pointer is best-effort.
Fix formatting of doc comment
Fix mistake in cranelift codegen
* Do not generate llvm.returnaddress on wasm
* Supress return_address test on miri
Reject implementing const Drop for types that are not const `Destruct` already
fixesrust-lang/rust#155618
While there is no soundness or otherwise issue currently, this PR ensures that people get what they expect. It seems wrong to allow implementing `const Drop`, but then the type still can't be dropped at compile-time.
r? @fee1-dead
Add intrinsic for launch-sized workgroup memory on GPUs
Workgroup memory is a memory region that is shared between all
threads in a workgroup on GPUs. Workgroup memory can be allocated
statically or after compilation, when launching a gpu-kernel.
The intrinsic added here returns the pointer to the memory that is
allocated at launch-time.
# Interface
With this change, workgroup memory can be accessed in Rust by
calling the new `gpu_launch_sized_workgroup_mem<T>() -> *mut T`
intrinsic.
It returns the pointer to workgroup memory guaranteeing that it is
aligned to at least the alignment of `T`.
The pointer is dereferencable for the size specified when launching the
current gpu-kernel (which may be the size of `T` but can also be larger
or smaller or zero).
All calls to this intrinsic return a pointer to the same address.
See the intrinsic documentation for more details.
## Alternative Interfaces
It was also considered to expose dynamic workgroup memory as extern
static variables in Rust, like they are represented in LLVM IR.
However, due to the pointer not being guaranteed to be dereferencable
(that depends on the allocated size at runtime), such a global must be
zero-sized, which makes global variables a bad fit.
# Implementation Details
Workgroup memory in amdgpu and nvptx lives in address space 3.
Workgroup memory from a launch is implemented by creating an
external global variable in address space 3. The global is declared with
size 0, as the actual size is only known at runtime. It is defined
behavior in LLVM to access an external global outside the defined size.
There is no similar way to get the allocated size of launch-sized
workgroup memory on amdgpu an nvptx, so users have to pass this
out-of-band or rely on target specific ways for now.
Tracking issue: rust-lang/rust#135516
privacy: Assert that compared visibilities are (usually) ordered
And make "greater than" (`>`) the new primary operation for comparing visibilities instead of "is at least" (`>=`).
Workgroup memory is a memory region that is shared between all
threads in a workgroup on GPUs. Workgroup memory can be allocated
statically or after compilation, when launching a gpu-kernel.
The intrinsic added here returns the pointer to the memory that is
allocated at launch-time.
# Interface
With this change, workgroup memory can be accessed in Rust by
calling the new `gpu_launch_sized_workgroup_mem<T>() -> *mut T`
intrinsic.
It returns the pointer to workgroup memory guaranteeing that it is
aligned to at least the alignment of `T`.
The pointer is dereferencable for the size specified when launching the
current gpu-kernel (which may be the size of `T` but can also be larger
or smaller or zero).
All calls to this intrinsic return a pointer to the same address.
See the intrinsic documentation for more details.
## Alternative Interfaces
It was also considered to expose dynamic workgroup memory as extern
static variables in Rust, like they are represented in LLVM IR.
However, due to the pointer not being guaranteed to be dereferencable
(that depends on the allocated size at runtime), such a global must be
zero-sized, which makes global variables a bad fit.
# Implementation Details
Workgroup memory in amdgpu and nvptx lives in address space 3.
Workgroup memory from a launch is implemented by creating an
external global variable in address space 3. The global is declared with
size 0, as the actual size is only known at runtime. It is defined
behavior in LLVM to access an external global outside the defined size.
There is no similar way to get the allocated size of launch-sized
workgroup memory on amdgpu an nvptx, so users have to pass this
out-of-band or rely on target specific ways for now.
Matthias Krüger