pub type AliasConstKind<'tcx> = AliasConstKind<TyCtxt<'tcx>>;Aliased Type§
pub enum AliasConstKind<'tcx> {
Projection {
def_id: DefId,
},
InherentSelf {
def_id: DefId,
},
InherentImpl {
def_id: DefId,
},
Free {
def_id: DefId,
},
Anon {
def_id: DefId,
},
}Variants§
Projection
A projection <Type as Trait>::AssocConst
InherentSelf
An associated const in an inherent impl.
The generic args are in “Self form”, i.e.
there is a single Self type parameter, followed by any GAT args on the inherent const
itself.
The “impl form” args can be obtained by generating fresh vars for each of the impl params,
instantiating the impl block’s Self type with the fresh vars, equating the resulting type
with the Self generic argument, and using the result of what the fresh vars resolved to as
the “impl form” args. Doing so without considering the extra predicates generated by the
equate is a lossy operation, consider the following impl block:
impl<T> Struct<'static, T> {
const ASSOC<A>: () = ();
}If we have Struct::<'a, u32>::Assoc<usize>, the Self args form would be [Struct<'a, u32>, usize]. The “impl form” args would be [u32, usize], with an extra constraint generated
that 'a == 'static. Disregarding this extra constraint would be wrong.
Hence, when HIR lowering wants to construct an inherent alias, it must use the “Self form” to let the trait solver do the equate and consider additional constraints.
FIXME(inherent_associated_types): This ideally ought be a list of candidate DefIds that a
path could resolve to, then the trait solver does the above-written routine to figure out
which exact impl to use. InherentSelf could be conceptually be thought of as corresponding
to Projection where the def_id is a trait, and InherentImpl is Projection where the
def_id is an impl.
InherentImpl
An associated const in an inherent impl. See [Self::InherentSelf] for a description on
the difference between InherentSelf and InherentImpl.
Free
A free constant, outside an impl block.
Anon
Anonymous constant, e.g. the 1 + 2 in [u8; 1 + 2].
Layout§
Note: Unable to compute type layout, possibly due to this type having generic parameters. Layout can only be computed for concrete, fully-instantiated types.