Dotty Documentation



[-] Constructors

[-] Members

[+] object Annotations
[+] class CheckRealizable

Compute realizability status

[+] object CheckRealizable

Realizability status

[+] class ClassfileLoader
[+] object Comments
[+] object Constants
[+] abstract class Constraint

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.
[+] trait ConstraintHandling

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.

[+] trait ConstraintRunInfo
[+] object Contexts
[+] object Decorators

This object provides useful implicit decorators for types defined elsewhere

[+] class Definitions

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.

[+] object Definitions
[+] object DenotTransformers
[+] object Denotations

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

[+] object Flags
[+] object Hashable
[+] trait Hashable
[+] final case class Mode

A collection of mode bits that are part of a context

[+] object Mode
[+] class MutableTyperState
[+] object NameKinds

Defines possible kinds of NameInfo of a derived name

[+] object NameOps
[+] object Names
[+] class OrderingConstraint

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

[+] object OrderingConstraint
[+] object ParamInfo
[+] trait ParamInfo

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

[+] abstract class Periods

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

[+] object Periods
[+] object PhantomErasure

Phantom erasure erases (minimal erasure):

  • Parameters/arguments are erased to ErasedPhantom. The next step will remove the parameters from the method definitions and calls (implemented in branch implement-phantom-types-part-2).
  • Definitions of def, val, lazy val and var returning a phantom type to return a ErasedPhantom. Where fields with ErasedPhantom type are not memoized (see transform/Memoize.scala).
  • Calls to Phantom.assume become calls to ErasedPhantom.UNIT. Intended to be optimized away by local optimizations.
[+] object Phases
[+] trait Phases
[+] object Scopes
[+] case class Signature

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

  List("scala.Int".toTypeName, "scala.collection.immutable.List".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
[+] object Signature
[+] class SourcefileLoader
[+] object StdNames
[+] trait Substituters

Substitution operations on types. See the corresponding subst and substThis methods on class Type for an explanation.

[+] object SymDenotations
[+] trait SymDenotations
[+] abstract class SymbolLoader

A lazy type that completes itself by calling parameter doComplete. Any linked modules/classes or module classes are also initialized.

[+] class SymbolLoaders

A base class for Symbol loaders with some overridable behavior

[+] object SymbolLoaders
[+] object Symbols
[+] trait Symbols

Creation methods for symbols

[+] final class TypeApplications

A decorator that provides methods for modeling type application

[+] object TypeApplications
[+] class TypeComparer

Provides methods to compare types.

[+] object TypeComparer
[+] class TypeErasure
[+] object TypeErasure

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

[+] object TypeOps
[+] trait TypeOps
[+] class TyperState
[+] object Types
[+] object Uniques

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.