Every lifting root calls `unwrap`/`expect` on the result, except for
`ImmTy::fmt` but there's no good reason for that exception. Making
lifting infallible is sensible because it should only fail if the wrong
interner is somehow used, which indicates a major bug in rustc rather
than an error condition.
Various places where `lift` just isn't necessary. Either because we're
not within a closure passed to `tls::with`, or because the type being lifted
doesn't have a `'tcx` lifetime.
`ty::Alias` refactor
This PR changes the following alias-related types from this:
```rust
pub enum AliasTyKind {
Projection,
Inherent,
Opaque,
Free,
}
pub struct AliasTy<I: Interner> {
pub args: I::GenericArgs,
pub def_id: I::DefId,
}
pub enum TyKind<I: Interner> {
...
Alias(AliasTyKind, AliasTy<I>),
}
```
Into this:
```rust
pub enum AliasTyKind<I: Interner> {
Projection { def_id: I::DefId },
Inherent { def_id: I::DefId },
Opaque { def_id: I::DefId },
Free { def_id: I::DefId },
}
pub struct AliasTy<I: Interner> {
pub args: I::GenericArgs,
pub kind: AliasTyKind<I>,
}
pub enum TyKind<I: Interner> {
...
Alias(AliasTy<I>),
}
```
... and then does a thousand other changes to accommodate for this change everywhere.
This brings us closer to being able to have `AliasTyKind`s which don't require a `DefId` (and thus can be more easily created, etc). Although notably we depend on both `AliasTyKind -> DefId` and `DefId -> AliasTyKind` conversions in a bunch of places still.
r? lcnr
----
A lot of these changes were done either by search & replace (via `ast-grep`) or on auto pilot, so I'm not quite sure I didn't mess up somewhere, but at least tests pass...
Because the things in this module aren't MIR and don't use anything
from `rustc_middle::mir`. Also, modules that use `mono` often don't use
anything else from `rustc_middle::mir`.
Instead of just using regular struct lowering for these types, which
results in an incorrect ABI (e.g. returning indirectly), use
`BackendRepr::ScalableVector` which will lower to the correct type and
be passed in registers.
This also enables some simplifications for generating alloca of scalable
vectors and greater re-use of `scalable_vector_parts`.
A LLVM codegen test demonstrating the changed IR this generates is
included in the next commit alongside some intrinsics that make these
tuples usable.
refactor(mgca): Change `DefKind::Const` and `DefKind::AssocConst` to have a `is_type_const` flag
Addresses rust-lang/rust#152940
- Changed `DefKind::Const` and `DefKind::AssocConst` to have a `is_type_const` flag.
- changed `is_type_const` query to check for this flag
- removed `is_rhs_type_const` query
r? @BoxyUwU
* refactor: add `is_type_const` flag to `DefKind::Const` and `AssocConst`
* refactor(cleanup) remove the `rhs_is_type_const` query
* style: fix formatting
* refactor: refactor stuff in librustdoc for new Const and AssocConst
* refactor: refactor clippy for the changes
* chore: formatting
* fix: fix test
* fix: fix suggestions
* Update context.rs
Co-authored-by: Boxy <rust@boxyuwu.dev>
* changed AssocKind::Const to store data about being a type const
rustc_public: remove the `CrateDefItems` trait
This trait feels sus since its documentation says it's for 'retrieving all items from a definition' however it only provides an `associated_items` method (??), which I believe should only be valid for `impl`s and `trait`s.
rustc_public: Make fields that shouldn't be exposed visible only in `rustc_public`
Previously these fields had to be public since the convert logic was in the `rustc_smir` crate, however that is no longer the case today.
Don't expose redundant information in `rustc_public`'s `LayoutShape`
Enum variant layouts don't need to store a full `LayoutShape`; just storing the fields offsets is enough and all other information can be inferred from the parent layout:
- size, align and ABI don't make much sense for individual variants and should generally be taken from the parent layout instead;
- variants always have `fields: FieldsShape::Arbitrary { .. }` and `variant: VariantShape::Single { .. }`.
In principle, the same refactor could be done on `rustc_abi::Layout` (see [this comment](https://github.com/rust-lang/rust/issues/113988#issuecomment-1646982272)) but I prefer starting with this smaller change first.
abi: add a rust-preserve-none calling convention
This is the conceptual opposite of the rust-cold calling convention and is particularly useful in combination with the new `explicit_tail_calls` feature.
For relatively tight loops implemented with tail calling (`become`) each of the function with the regular calling convention is still responsible for restoring the initial value of the preserved registers. So it is not unusual to end up with a situation where each step in the tail call loop is spilling and reloading registers, along the lines of:
foo:
push r12
; do things
pop r12
jmp next_step
This adds up quickly, especially when most of the clobberable registers are already used to pass arguments or other uses.
I was thinking of making the name of this ABI a little less LLVM-derived and more like a conceptual inverse of `rust-cold`, but could not come with a great name (`rust-cold` is itself not a great name: cold in what context? from which perspective? is it supposed to mean that the function is rarely called?)
This is the conceptual opposite of the rust-cold calling convention and
is particularly useful in combination with the new `explicit_tail_calls`
feature.
For relatively tight loops implemented with tail calling (`become`) each
of the function with the regular calling convention is still responsible
for restoring the initial value of the preserved registers. So it is not
unusual to end up with a situation where each step in the tail call loop
is spilling and reloading registers, along the lines of:
foo:
push r12
; do things
pop r12
jmp next_step
This adds up quickly, especially when most of the clobberable registers
are already used to pass arguments or other uses.
I was thinking of making the name of this ABI a little less LLVM-derived
and more like a conceptual inverse of `rust-cold`, but could not come
with a great name (`rust-cold` is itself not a great name: cold in what
context? from which perspective? is it supposed to mean that the
function is rarely called?)
Removes the attribute from `MetaSized` and `PointeeSized`, with a special case in the trait solvers for `MetaSized`.
`dyn MetaSized` is a perfectly cromulent type, and seems to only have had #[rustc_do_not_implement_via_object] so the builtin object
candidate does not overlap with the builtin MetaSized impl that all `dyn` types get.
Resolves this with a special case by checking `is_sizedness_trait` where the trait solvers previously checked `implement_via_object`.
`dyn PointeeSized` alone is rejected for other reasons (since `dyn PointeeSized` is considered to have no principal trait because `PointeeSized`
is removed at an earlier stage of the compiler), but `(dyn PointeeSized + Send)` is valid and equivalent to `dyn Send`.
Add suggestions from code review
Update compiler/rustc_trait_selection/src/traits/dyn_compatibility.rs and tests
Co-authored-by: lcnr <rust@lcnr.de>
Enum variant layouts don't need to store a full `LayoutShape`; just storing
the fields offsets is enough and all other information can be inferred from
the parent layout:
- size, align and ABI don't make much sense for individual variants and
should generally be taken from the parent layout instead;
- variants always have `fields: FieldsShape::Arbitrary { .. }` and
`variant: VariantShape::Single { .. }`.
Replace Rvalue::NullaryOp by a variant in mir::Operand.
Based on https://github.com/rust-lang/rust/pull/148151
This PR fully removes the MIR `Rvalue::NullaryOp`. After rust-lang/rust#148151, it was only useful for runtime checks like `ub_checks`, `contract_checks` and `overflow_checks`.
These are "runtime" checks, boolean constants that may only be `true` in codegen. It depends on a rustc flag passed to codegen, so we need to represent those flags cross-crate.
This PR replaces those runtime checks by special variants in MIR `ConstValue`. This allows code that expects constants to manipulate those as such, even if we may not always be able to evaluate them to actual scalars.
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>
Fix `name()` functions for local defs in rustc_public
This change fixes the behavior of the `name()` function for `CrateDef` and `Instance` which should return absolute path of items. For local items, the crate name was missing.
This resolves: https://github.com/rust-lang/project-stable-mir/issues/109
Add `DefId::parent()` accessor for `rustc_public`
Adds a `parent()` method to `DefId` (the `rustc_pub` version) which exposes the parent path, ie. `foo::bar::baz` -> `foo::bar`.
This is useful for organizing/grouping definitions into a tree, and is probably simpler and less brittle than attempting to parse the fully-qualified name into path components (e.g. especially when handling path components with qualified generic parameters).
Fix some issues around `rustc_public`
cc rust-lang/rust#148266 .
follow-up of rust-lang/rust#148341 .
This fixes the issues that can be reproduced by `x test compiler/rustc_public`:
```
error: function `run` is never used
--> compiler/rustc_public/src/compiler_interface.rs:838:15
|
838 | pub(crate) fn run<'tcx, F, T>(interface: &CompilerInterface<'tcx>, f: F) -> Result<T, Error>
| ^^^
|
= note: `-D dead-code` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(dead_code)]`
error: unreachable `pub` item
--> compiler/rustc_public/src/unstable/mod.rs:25:1
|
25 | pub trait InternalCx<'tcx>: Copy + Clone {
| ---^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| |
| help: consider restricting its visibility: `pub(crate)`
|
= help: or consider exporting it for use by other crates
= note: `-D unreachable-pub` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(unreachable_pub)]`
error: unreachable `pub` item
--> compiler/rustc_public/src/unstable/mod.rs:62:1
|
62 | pub trait Stable<'tcx>: PointeeSized {
| ---^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| |
| help: consider restricting its visibility: `pub(crate)`
|
= help: or consider exporting it for use by other crates
error: unreachable `pub` item
--> compiler/rustc_public/src/unstable/mod.rs:81:1
|
81 | pub trait RustcInternal {
| ---^^^^^^^^^^^^^^^^^^^^
| |
| help: consider restricting its visibility: `pub(crate)`
|
= help: or consider exporting it for use by other crates
error: could not compile `rustc_public` (lib) due to 4 previous errors
```
Ralf Jung