Trait rustc_ap_rustc_data_structures::unify::UnifyKey

pub trait UnifyKey: Clone + PartialEq<Self> + Copy + Debug {
    type Value: UnifyValue;
    fn index(&self) -> u32;
    fn from_index(u: u32) -> Self;
    fn tag() -> &'static str;

    fn order_roots(
        a: Self, 
        a_value: &Self::Value, 
        b: Self, 
        b_value: &Self::Value
    ) -> Option<(Self, Self)> { ... }
}

This trait is implemented by any type that can serve as a type variable. We call such variables unification keys. For example, this trait is implemented by IntVid, which represents integral variables.

Each key type has an associated value type V. For example, for IntVid, this is Option<IntVarValue>, representing some (possibly not yet known) sort of integer.

Clients are expected to provide implementations of this trait; you can see some examples in the test module.

Associated Types

type Value: UnifyValue

Loading content...

Required methods

fn index(&self) -> u32

fn from_index(u: u32) -> Self

fn tag() -> &'static str

Loading content...

Provided methods

fn order_roots(
    a: Self,
    a_value: &Self::Value,
    b: Self,
    b_value: &Self::Value
) -> Option<(Self, Self)>

If true, then self should be preferred as root to other. Note that we assume a consistent partial ordering, so returning true implies that other.prefer_as_root_to(self) would return false. If there is no ordering between two keys (i.e., a.prefer_as_root_to(b) and b.prefer_as_root_to(a) both return false) then the rank will be used to determine the root in an optimal way.

NB. The only reason to implement this method is if you want to control what value is returned from find(). In general, it is better to let the unification table determine the root, since overriding the rank can cause execution time to increase dramatically.

Loading content...

Implementors

Loading content...