Compute realizability status
Constraint over undetermined type parameters. Constraints are built over values of the following types:
- TypeLambda A constraint constrains the type parameters of a set of TypeLambdas
- TypeParamRef The parameters of the constrained type lambdas
- TypeVar Every constrained parameter might be associated with a TypeVar that has the TypeParamRef as origin.
Methods for adding constraints and solving them.
What goes into a Constraint as opposed to a ConstrainHandler?
Constraint code is purely functional: Operations get constraints and produce new ones. Constraint code does not have access to a type-comparer. Anything regarding lubs and glbs has to be done elsewhere.
By comparison: Constraint handlers are parts of type comparers and can use their functionality. Constraint handlers update the current constraint as a side effect.
This TypeError signals that completing denot encountered a cycle: it asked for denot.info (or similar), so it requires knowing denot already.
This object provides useful implicit decorators for types defined elsewhere
A class defining symbols and types of standard definitions
Note: There's a much nicer design possible once we have implicit functions. The idea is explored to some degree in branch wip-definitions (#929): Instead of a type and a separate symbol definition, we produce in one line an implicit function from Context to Symbol, and possibly also the corresponding type. This cuts down on all the duplication encountered here.
wip-definitions tries to do the same with an implicit conversion from a SymbolPerRun type to a symbol type. The problem with that is universal equality. Comparisons will not trigger the conversion and will therefore likely return false results.
So the branch is put on hold, until we have implicit functions, which will always automatically be dereferenced.
Denotations represent the meaning of symbols and named types.
The following diagram shows how the principal types of denotations
and their denoting entities relate to each other. Lines ending in
v are member methods. The two methods shown in the diagram are
"symbol" and "deref". Both methods are parameterized by the current context,
and are effectively indexed by current period.
Lines ending in a horizontal line mean subtying (right is a subtype of left).
NamedType | Symbol---------ClassSymbol | | | | denot | denot | denot v v v Denotation-+-----SingleDenotation-+------SymDenotation-+----ClassDenotation | | +-----MultiDenotation | | +--UniqueRefDenotation +--JointRefDenotation
Here's a short summary of the classes in this diagram.
NamedType A type consisting of a prefix type and a name, with fields prefix: Type name: Name It has two subtypes: TermRef and TypeRef Symbol A label for a definition or declaration in one compiler run ClassSymbol A symbol representing a class Denotation The meaning of a named type or symbol during a period MultiDenotation A denotation representing several overloaded members SingleDenotation A denotation representing a non-overloaded member or definition, with main fields symbol: Symbol info: Type UniqueRefDenotation A denotation referring to a single definition with some member type JointRefDenotation A denotation referring to a member that could resolve to several definitions SymDenotation A denotation representing a single definition with its original type, with main fields name: Name owner: Symbol flags: Flags privateWithin: Symbol annotations: List[Annotation] ClassDenotation A denotation representing a single class definition.
A type comparer that can record traces of subtype operations
A collection of mode bits that are part of a context
Defines possible kinds of NameInfo of a derived name
The possible tags of a NameKind
Constraint over undetermined type parameters that keeps separate maps to reflect parameter orderings.
A common super trait of Symbol and LambdaParam. Used to capture the attributes of type parameters which can be implemented as either.
Periods are the central "clock" of the compiler. A period consists of a run id and a phase id. run ids represent compiler runs phase ids represent compiler phases
The signature of a denotation. Overloaded denotations with the same name are distinguished by their signatures. A signature of a method (of type PolyType,MethodType, or ExprType) is composed of a list of signature names, one for each parameter type, plus a signature for the result type. Methods are uncurried before taking their signatures. The signature name of a type is the fully qualified name of the type symbol of the type's erasure.
For instance a definition
def f(x: Int)(y: List[String]): String
would have signature
Signature( List("scala.Int".toTypeName, "scala.collection.immutable.List".toTypeName), "scala.String".toTypeName)
The signatures of non-method types are always
There are three kinds of "missing" parts of signatures:
- tpnme.EMPTY Result type marker for NotAMethod and OverloadedSignature
- tpnme.WILDCARD Arises from a Wildcard or error type
- tpnme.Uninstantiated Arises from an uninstantiated type variable
Substitution operations on types. See the corresponding
substThis methods on class Type for an explanation.
A lazy type that completes itself by calling parameter doComplete. Any linked modules/classes or module classes are also initialized.
Creation methods for symbols
Temporary, reusable reporter used in TyperState#test
A decorator that provides methods for modeling type application
Provides methods to compare types.
Erased types are:
ErasedValueType TypeRef(prefix is ignored, denot is ClassDenotation) TermRef(prefix is ignored, denot is SymDenotation) JavaArrayType AnnotatedType MethodType ThisType SuperType ClassInfo (NoPrefix, ...) NoType NoPrefix WildcardType ErrorType
only for isInstanceOf, asInstanceOf: PolyType, TypeParamRef, TypeBounds
unique for hash-consing types.
Also defines specialized hash sets for hash consing uniques of a specific type.
All sets offer a
enterIfNew method which checks whether a type
with the given parts exists already and creates a new one if not.