ConstraintHandling

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

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.