Struct rustc_trait_selection::infer::at::At

pub struct At<'a, 'tcx> {
    pub infcx: &'a InferCtxt<'a, 'tcx>,
    pub cause: &'a ObligationCause<'tcx>,
    pub param_env: ParamEnv<'tcx>,
}

Fields

infcx: &'a InferCtxt<'a, 'tcx>

cause: &'a ObligationCause<'tcx>

param_env: ParamEnv<'tcx>

Implementations

impl<'a, 'tcx> At<'a, 'tcx>

pub fn eq_impl_headers(
    self,
    expected: &ImplHeader<'tcx>,
    actual: &ImplHeader<'tcx>
) -> Result<InferOk<'tcx, ()>, TypeError<'tcx>>

Hacky routine for equating two impl headers in coherence.

pub fn sub_exp<T>(
    self,
    a_is_expected: bool,
    a: T,
    b: T
) -> Result<InferOk<'tcx, ()>, TypeError<'tcx>> where
    T: ToTrace<'tcx>, 

Makes a <: b, where a may or may not be expected.

pub fn sup<T>(
    self,
    expected: T,
    actual: T
) -> Result<InferOk<'tcx, ()>, TypeError<'tcx>> where
    T: ToTrace<'tcx>, 

Makes actual <: expected. For example, if type-checking a call like foo(x), where foo: fn(i32), you might have sup(i32, x), since the "expected" type is the type that appears in the signature.

pub fn sub<T>(
    self,
    expected: T,
    actual: T
) -> Result<InferOk<'tcx, ()>, TypeError<'tcx>> where
    T: ToTrace<'tcx>, 

Makes expected <: actual.

pub fn eq_exp<T>(
    self,
    a_is_expected: bool,
    a: T,
    b: T
) -> Result<InferOk<'tcx, ()>, TypeError<'tcx>> where
    T: ToTrace<'tcx>, 

Makes expected <: actual.

pub fn eq<T>(
    self,
    expected: T,
    actual: T
) -> Result<InferOk<'tcx, ()>, TypeError<'tcx>> where
    T: ToTrace<'tcx>, 

Makes expected <: actual.

pub fn relate<T>(
    self,
    expected: T,
    variance: Variance,
    actual: T
) -> Result<InferOk<'tcx, ()>, TypeError<'tcx>> where
    T: ToTrace<'tcx>, 

pub fn lub<T>(
    self,
    expected: T,
    actual: T
) -> Result<InferOk<'tcx, T>, TypeError<'tcx>> where
    T: ToTrace<'tcx>, 

Computes the least-upper-bound, or mutual supertype, of two values. The order of the arguments doesn't matter, but since this can result in an error (e.g., if asked to compute LUB of u32 and i32), it is meaningful to call one of them the "expected type".

pub fn glb<T>(
    self,
    expected: T,
    actual: T
) -> Result<InferOk<'tcx, T>, TypeError<'tcx>> where
    T: ToTrace<'tcx>, 

Computes the greatest-lower-bound, or mutual subtype, of two values. As with lub order doesn't matter, except for error cases.

pub fn trace<T>(self, expected: T, actual: T) -> Trace<'a, 'tcx> where
    T: ToTrace<'tcx>, 

Sets the "trace" values that will be used for error-reporting, but doesn't actually perform any operation yet (this is useful when you want to set the trace using distinct values from those you wish to operate upon).

pub fn trace_exp<T>(self, a_is_expected: bool, a: T, b: T) -> Trace<'a, 'tcx> where
    T: ToTrace<'tcx>, 

Like trace, but the expected value is determined by the boolean argument (if true, then the first argument a is the "expected" value).

Trait Implementations

impl<'cx, 'tcx> AtExt<'tcx> for At<'cx, 'tcx>

fn dropck_outlives(&self, ty: Ty<'tcx>) -> InferOk<'tcx, Vec<GenericArg<'tcx>>>

Given a type ty of some value being dropped, computes a set of "kinds" (types, regions) that must be outlive the execution of the destructor. These basically correspond to data that the destructor might access. This is used during regionck to impose "outlives" constraints on any lifetimes referenced within.

The rules here are given by the "dropck" RFCs, notably #1238 and #1327. This is a fixed-point computation, where we explore all the data that will be dropped (transitively) when a value of type ty is dropped. For each type T that will be dropped and which has a destructor, we must assume that all the types/regions of T are live during the destructor, unless they are marked with a special attribute (#[may_dangle]).

impl<'cx, 'tcx> AtExt<'tcx> for At<'cx, 'tcx>

fn normalize<T>(&self, value: &T) -> Result<Normalized<'tcx, T>, NoSolution> where
    T: TypeFoldable<'tcx>, 

Normalize value in the context of the inference context, yielding a resulting type, or an error if value cannot be normalized. If you don't care about regions, you should prefer normalize_erasing_regions, which is more efficient.

If the normalization succeeds and is unambiguous, returns back the normalized value along with various outlives relations (in the form of obligations that must be discharged).

N.B., this will eventually be the main means of normalizing, but for now should be used only when we actually know that normalization will succeed, since error reporting and other details are still "under development".