Compute realizability status

Realizability status

Constraint over undetermined type parameters. Constraints are built over values of the following types:

• PolyType A constraint constrains the type parameters of a set of PolyTypes
• PolyParam The parameters of the constrained polytypes
• TypeVar Every constrained parameter might be associated with a TypeVar that has the PolyParam 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 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 a down-arrow 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------TermRefWithSignature | | Symbol---------ClassSymbol | | | | | denot | denot | denot | denot v 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 TermRefWithSignature A TermRef that has in addition a signature to select an overloaded variant, with new field sig: Signature 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

Constraint over undetermined type parameters that keeps separate maps to reflect parameter orderings.

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 NotAMethod.

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 subst and 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.

A base class for Symbol loaders with some overridable behavior

Creation methods for symbols

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, PolyParam, TypeBounds

A common super trait of Symbol and LambdaParam. Used to capture the attributes of type parameters which can be implemented as either.

Defines operation 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.