1 //! # Lattice variables
3 //! Generic code for operating on [lattices] of inference variables
4 //! that are characterized by an upper- and lower-bound.
6 //! The code is defined quite generically so that it can be
7 //! applied both to type variables, which represent types being inferred,
8 //! and fn variables, which represent function types being inferred.
9 //! (It may eventually be applied to their types as well.)
10 //! In some cases, the functions are also generic with respect to the
11 //! operation on the lattice (GLB vs LUB).
15 //! Although all the functions are generic, for simplicity, comments in the source code
16 //! generally refer to type variables and the LUB operation.
18 //! [lattices]: https://en.wikipedia.org/wiki/Lattice_(order)
20 use super::type_variable::{TypeVariableOrigin, TypeVariableOriginKind};
23 use crate::traits::ObligationCause;
24 use rustc_middle::ty::relate::{RelateResult, TypeRelation};
25 use rustc_middle::ty::TyVar;
26 use rustc_middle::ty::{self, Ty};
28 /// Trait for returning data about a lattice, and for abstracting
29 /// over the "direction" of the lattice operation (LUB/GLB).
31 /// GLB moves "down" the lattice (to smaller values); LUB moves
32 /// "up" the lattice (to bigger values).
33 pub trait LatticeDir<'f, 'tcx>: TypeRelation<'tcx> {
34 fn infcx(&self) -> &'f InferCtxt<'f, 'tcx>;
36 fn cause(&self) -> &ObligationCause<'tcx>;
38 // Relates the type `v` to `a` and `b` such that `v` represents
39 // the LUB/GLB of `a` and `b` as appropriate.
41 // Subtle hack: ordering *may* be significant here. This method
42 // relates `v` to `a` first, which may help us to avoid unnecessary
43 // type variable obligations. See caller for details.
44 fn relate_bound(&mut self, v: Ty<'tcx>, a: Ty<'tcx>, b: Ty<'tcx>) -> RelateResult<'tcx, ()>;
47 /// Relates two types using a given lattice.
48 pub fn super_lattice_tys<'a, 'tcx: 'a, L>(
52 ) -> RelateResult<'tcx, Ty<'tcx>>
54 L: LatticeDir<'a, 'tcx>,
56 debug!("{}.lattice_tys({:?}, {:?})", this.tag(), a, b);
62 let infcx = this.infcx();
63 let a = infcx.inner.borrow_mut().type_variables().replace_if_possible(a);
64 let b = infcx.inner.borrow_mut().type_variables().replace_if_possible(b);
65 match (a.kind(), b.kind()) {
66 // If one side is known to be a variable and one is not,
67 // create a variable (`v`) to represent the LUB. Make sure to
68 // relate `v` to the non-type-variable first (by passing it
69 // first to `relate_bound`). Otherwise, we would produce a
70 // subtype obligation that must then be processed.
72 // Example: if the LHS is a type variable, and RHS is
73 // `Box<i32>`, then we current compare `v` to the RHS first,
74 // which will instantiate `v` with `Box<i32>`. Then when `v`
75 // is compared to the LHS, we instantiate LHS with `Box<i32>`.
76 // But if we did in reverse order, we would create a `v <:
77 // LHS` (or vice versa) constraint and then instantiate
78 // `v`. This would require further processing to achieve same
79 // end-result; in partiular, this screws up some of the logic
80 // in coercion, which expects LUB to figure out that the LHS
81 // is (e.g.) `Box<i32>`. A more obvious solution might be to
82 // iterate on the subtype obligations that are returned, but I
83 // think this suffices. -nmatsakis
84 (&ty::Infer(TyVar(..)), _) => {
85 let v = infcx.next_ty_var(TypeVariableOrigin {
86 kind: TypeVariableOriginKind::LatticeVariable,
87 span: this.cause().span,
89 this.relate_bound(v, b, a)?;
92 (_, &ty::Infer(TyVar(..))) => {
93 let v = infcx.next_ty_var(TypeVariableOrigin {
94 kind: TypeVariableOriginKind::LatticeVariable,
95 span: this.cause().span,
97 this.relate_bound(v, a, b)?;
101 _ => infcx.super_combine_tys(this, a, b),