TypeComparer

Form a normalized conjunction of two types. Note: For certain types, & is distributed inside the type. This holds for all types which are not value types (e.g. TypeBounds, ClassInfo, ExprType, LambdaType). Also, when forming an &, instantiated TypeVars are dereferenced and annotations are stripped. Finally, refined types with the same refined name are opportunistically merged.

If both tp1 and tp2 have atoms information, compare the atoms in a Some, otherwise None.

Optionally, the constant c such that tp <:< ConstantType(c)

Can comparing this type on the left lead to an either? This is the case if the type is and AndType or contains embedded occurrences of AndTypes

Decompose into conjunction of types each of which has only a single refinement

The trace of comparison operations when performing op

The greatest lower bound of two types

Try to produce joint arguments for a glb A[T_1, ..., T_n] & A[T_1', ..., T_n'] using the following strategies:

• if arguments are the same, that argument.
• if corresponding parameter variance is co/contra-variant, the glb/lub.
• if at least one of the arguments if a TypeBounds, the union of the bounds.
• if homogenizeArgs is set, and arguments can be unified by instantiating type parameters, the unified argument.
• otherwise NoType

The unification rule is contentious because it cuts the constraint set. Therefore it is subject to Config option alignArgsInAnd.

Defer constraining type variables when compared against prototypes

Same as isSameType but also can be applied to overloaded TermRefs, where two overloaded refs are the same if they have pairwise equal alternatives

Two types are the same if are mutual subtypes of each other

Subtype test for corresponding arguments in args1, args2 according to variances in type parameters tparams2.

op(tp1, tp2) unless tp1 and tp2 are type-constructors. In the latter case, combine tp1 and tp2 under a type lambda like this:

[X1, ..., Xn] -> op(tp1[X1, ..., Xn], tp2[X1, ..., Xn])

The least upper bound of two types

Try to produce joint arguments for a lub A[T_1, ..., T_n] | A[T_1', ..., T_n'] using the following strategies:

• if arguments are the same, that argument.
• if corresponding parameter variance is co/contra-variant, the lub/glb.
• otherwise a TypeBounds containing both arguments

A function implementing tp1 matches tp2.

Do the parameter types of tp1 and tp2 match in a way that allows tp1 to override tp2 ? Two modes: precise or not. If precise is set (which is the default) this is the case if they're pairwise =:=. Otherwise parameters in tp2 must be subtypes of corresponding parameters in tp1.

Do the parameter types of tp1 and tp2 match in a way that allows tp1 to override tp2 ? This is the case if they're pairwise >:>.

Optionally, the n such that tp <:< ConstantType(Constant(n: Int))

Form a normalized conjunction of two types. Note: For certain types, | is distributed inside the type. This holds for all types which are not value types (e.g. TypeBounds, ClassInfo, ExprType, LambdaType). Also, when forming an |, instantiated TypeVars are dereferenced and annotations are stripped.

Are tp1 and tp2 provablyDisjoint types?

true implies that we found a proof; uncertainty defaults to false.

Proofs rely on the following properties of Scala types:

1. Single inheritance of classes
2. Final classes cannot be extended
3. ConstantTypes with distinct values are non intersecting
4. TermRefs with distinct values are non intersecting
5. There is no value of type Nothing

Note on soundness: the correctness of match types relies on on the property that in all possible contexts, the same match type expression is either stuck or reduces to the same case.

Is tp an empty type?

true implies that we found a proof; uncertainty defaults to false.

Record statistics about the total number of subtype checks and the number of "successful" subtype checks, i.e. checks that form part of a subtype derivation tree that's ultimately successful.

Show subtype goal that led to an assertion failure

If the range tp1..tp2 consist of a single type, that type, otherwise NoType. This is the case iftp1 =:= tp2, but also iftp1 <:< tp2,tp1is a singleton type, andtp2derives fromscala.Singleton` (or vice-versa). Examples of the latter case:

"name".type .. Singleton "name".type .. String & Singleton Singleton .. "name".type String & Singleton .. "name".type

All consist of the single type "name".type.

Is a subtype check in progress? In that case we may not permanently instantiate type variables, because the corresponding constraint might still be retracted and the instantiation should then be reversed.

A hook for showing subtype traces. Overridden in ExplainingTypeComparer

Add constraint param <: bound if fromBelow is false, param >: bound otherwise. bound is assumed to be in normalized form, as specified in firstTry and secondTry of TypeComparer. In particular, it should not be an alias type, lazy ref, typevar, wildcard type, error type. In addition, upper bounds may not be AndTypes and lower bounds may not be OrTypes. This is assured by the way isSubType is organized.

Add type lambda tl, possibly with type variables tvars, to current constraint and propagate all bounds.

Solve constraint set for given type parameter param. If fromBelow is true the parameter is approximated by its lower bound, otherwise it is approximated by its upper bound, unless the upper bound contains a reference to the parameter itself (such occurrences can arise for F-bounded types, addOneBound ensures that they never occur in the lower bound). Wildcard types in bounds are approximated by their upper or lower bounds. The constraint is left unchanged.

Is param assumed to be a sub- and super-type of any other type? This holds if TypeVarsMissContext is set unless param is a part of a MatchType that is currently normalized.

The current bounds of type parameter param

Can param be constrained with new bounds?

Check that constraint is fully propagated. See comment in Config.checkConstraintsPropagated

Derive type and GADT constraints that necessarily follow from a pattern with the given type matching a scrutinee of the given type.

This function breaks down scrutinee and pattern types into subcomponents between which there must be a subtyping relationship, and derives constraints from those relationships. We have the following situation in case of a (dynamic) pattern match:

 StaticScrutineeType           PatternType
                   \            /
                DynamicScrutineeType

In simple cases, it must hold that PatternType <: StaticScrutineeType:

      StaticScrutineeType
            |         \
            |          PatternType
            |         /
         DynamicScrutineeType

A good example of a situation where the above must hold is when static scrutinee type is the root of an enum, and the pattern is an unapply of a case class, or a case object literal (of that enum).

In slightly more complex cases, we may need to upcast StaticScrutineeType:

     SharedPatternScrutineeSuperType
            /         \

StaticScrutineeType PatternType \ / DynamicScrutineeType

This may be the case if the scrutinee is a singleton type or a path-dependent type. It is also the case for the following definitions:

trait Expr[T] trait IntExpr extends Expr[T] trait Const[T] extends Expr[T]

StaticScrutineeType = Const[T] PatternType = IntExpr

Union and intersection types are an additional complication - if either scrutinee or pattern are a union type, then the above relationships only need to hold for the "leaves" of the types.

Finally, if pattern type contains hk-types applied to concrete types (as opposed to type variables), or either scrutinee or pattern type contain type member refinements, the above relationships do not need to hold at all. Consider (where T1, T2 are unrelated traits):

StaticScrutineeType = { type T <: T1 } PatternType = { type T <: T2 }

In the above situation, DynamicScrutineeType can equal { type T = T1 & T2 }, but there is no useful relationship between StaticScrutineeType and PatternType (nor any of their subcomponents). Similarly:

StaticScrutineeType = Option[T1] PatternType = Some[T2]

Again, DynamicScrutineeType may equal Some[T1 & T2], and there's no useful relationship between the static scrutinee and pattern types. This does not apply if the pattern type is only applied to type variables, in which case the subtyping relationship "heals" the type.

Constrain "simple" patterns (see constrainPatternType).

This function attempts to modify pattern and scrutinee type s.t. the pattern must be a subtype of the scrutinee, or otherwise it cannot possibly match. In order to do that, we:

1. Rely on constrainPatternType to break the actual scrutinee/pattern types into subcomponents
2. Widen type parameters of scrutinee type that are not invariantly refined (see below) by the pattern type.
3. Wrap the pattern type in a skolem to avoid overconstraining top-level abstract types in scrutinee type
4. Check that WidenedScrutineeType <: NarrowedPatternType

Importantly, note that the pattern type may contain type variables.

Invariant refinement

Essentially, we say that D[B] extends C[B] s.t. refines parameter A of trait C[A] invariantly if when c: C[T] and c is instance of D, then necessarily c: D[T]. This is violated if A is variant:

trait C[+A] trait D[+B](val b: B) extends C[B] trait E extends DAny with C[String]

E is a counter-example to the above - if e: E, then e: C[String] and e is instance of D, but it is false that e: D[String]! This is a problem if we're constraining a pattern like the below:

def foo[T](c: C[T]): T = c match { case d: D[t] => d.b }

It'd be unsound for us to say that t <: T, even though that follows from D[t] <: C[T]. Note, however, that if D was a final class, we could rely on that relationship. To support typical case classes, we also assume that this relationship holds for them and their parent traits. This is enforced by checking that classes inheriting from case classes do not extend the parent traits of those case classes without also appropriately extending the relevant case class (see RefChecks#checkCaseClassInheritanceInvariant).

If tp is an intersection such that some operands are transparent trait instances and others are not, replace as many transparent trait instances as possible with Any as long as the result is still a subtype of bound. But fall back to the original type if the resulting widened type is a supertype of all dropped types (since in this case the type was not a true intersection of transparent traits and other types to start with).

Full bounds of param, including other lower/upper params.

Note that underlying operations perform subtype checks - for this reason, recursing on fullBounds of some param when comparing types might lead to infinite recursion. Consider bounds instead.

The instance type of param in the current constraint (which contains param). If fromBelow is true, the instance type is the lub of the parameter's lower bounds; otherwise it is the glb of its upper bounds. However, a lower bound instantiation can be a singleton type only if the upper bound is also a singleton type.

Test whether the lower bounds of all parameters in this constraint are a solution to the constraint.

Constraint c1 subsumes constraint c2, if under c2 as constraint we have for all poly params p defined in c2 as p >: L2 <: U2:

c1 defines p with bounds p >: L1 <: U1, and L2 <: L1, and U1 <: U2

Both c1 and c2 are required to derive from constraint pre, without adding any new type variables but possibly narrowing already registered ones with further bounds.

Widen inferred type inst with upper bound, according to the following rules:

1. If inst is a singleton type, or a union containing some singleton types, widen (all) the singleton type(s), provided the result is a subtype of bound. (i.e. inst.widenSingletons <:< bound succeeds with satisfiable constraint)
2. If inst is a union type, approximate the union type from above by an intersection of all common base types, provided the result is a subtype of bound.
3. Widen some irreducible applications of higher-kinded types to wildcard arguments (see @widenIrreducible).
4. Drop transparent traits from intersections (see @dropTransparentTraits).

Don't do these widenings if bound is a subtype of scala.Singleton. Also, if the result of these widenings is a TypeRef to a module class, and this type ref is different from inst, replace by a TermRef to its source module instead.

At this point we also drop the @Repeated annotation to avoid inferring type arguments with it, as those could leak the annotation to users (see run/inferred-repeated-result).

If tp is an applied match type alias which is also an unreducible application of a higher-kinded type to a wildcard argument, widen to the match type's bound, in order to avoid an unreducible application of higher-kinded type ... in inferred type" error in PostTyper. Fixes #11246.

Potentially a type lambda that is still instantiatable, even though the constraint is generally frozen.

We are currently comparing type lambdas. Used as a flag for optimization: when false, no need to do an expensive pruneLambdaParams

If the constraint is frozen we cannot add new bounds to the constraint.

If set, align arguments S1, S2when taking the glb T1 { X = S1 } & T2 { X = S2 } of a constraint upper bound for some type parameter. Aligning means computing S1 =:= S2 which may change the current constraint. See note in TypeComparer#distributeAnd.