A type map which checks that the only cycles in a type are F-bounds and that protects all F-bounded references by LazyRefs.
Check applied type trees for well-formedness. This means - all arguments are within their corresponding bounds - if type is a higher-kinded application with wildcard arguments, check that it or one of its supertypes can be reduced to a normal application. Unreducible applications correspond to general existentials, and we cannot handle those.
A general checkBounds method that can be used for TypeApply nodes as well as for AppliedTypeTree nodes. Also checks that type arguments to *-type parameters are fully applied.
Check that type arguments
args conform to corresponding bounds in
Note: This does not check the bounds of AppliedTypeTrees. These
are handled by method checkBounds in FirstTransform
Verify classes extending AnyVal meet the requirements
tp refers to a nonAbstract class
and that the instance conforms to the self type of the created class.
Check the type signature of the symbol
M defined by
tree does not refer
to a private type or value which is invisible at a point where
M is still
As an exception, we allow references to type aliases if the underlying
type of the alias is not a leak, and if
sym is not a type. The rationale
for this is that the inferred type of a term symbol might contain leaky
aliases which should be removed (see leak-inferred.scala for an example),
but a type symbol definition will not contain leaky aliases unless the
user wrote them, so we can ask the user to change his definition. The more
practical reason for not transforming types is that
can force a lot of denotations, and this restriction means that we never
need to run
TypeAssigner#avoidPrivateLeaks on type symbols when
unpickling, which avoids some issues related to forcing order.
See i997.scala for negative tests, and i1130.scala for a case where it matters that we transform leaky aliases away.
info of symbol
sym is not cyclic.
Check that type
tp is realizable.
Check that refinement satisfies the following two conditions
1. No part of it refers to a symbol that's defined in the same refinement
at a textually later point.
2. All references to the refinement itself via
this are followed by
Note: It's not yet clear what exactly we want to allow and what we want to rule out.
This depends also on firming up the DOT calculus. For the moment we only issue
deprecated warnings, not errors.