Perform the following adaptations of expression, pattern or type tree wrt to given mode mode and given prototype pt: (-1) For expressions with annotated types, let AnnotationCheckers decide what to do (0) Convert expressions with constant types to literals (unless in interactive/scaladoc mode) (1) Resolve overloading, unless mode contains FUNmode (2) Apply parameterless functions (3) Apply polymorphic types to fresh instances of their type parameters and store these instances in context.undetparams, unless followed by explicit type application. (4) Do the following to unapplied methods used as values: (4.1) If the method has only implicit parameters pass implicit arguments (4.2) otherwise, if pt is a function type and method is not a constructor, convert to function by eta-expansion, (4.3) otherwise, if the method is nullary with a result type compatible to pt and it is not a constructor, apply it to () otherwise issue an error (5) Convert constructors in a pattern as follows: (5.1) If constructor refers to a case class factory, set tree's type to the unique instance of its primary constructor that is a subtype of the expected type. (5.2) If constructor refers to an extractor, convert to application of unapply or unapplySeq method.

(6) Convert all other types to TypeTree nodes. (7) When in TYPEmode but not FUNmode or HKmode, check that types are fully parameterized (7.1) In HKmode, higher-kinded types are allowed, but they must have the expected kind-arity (8) When in both EXPRmode and FUNmode, add apply method calls to values of object type. (9) If there are undetermined type variables and not POLYmode, infer expression instance Then, if tree's type is not a subtype of expected type, try the following adaptations: (10) If the expected type is Byte, Short or Char, and the expression is an integer fitting in the range of that type, convert it to that type. (11) Widen numeric literals to their expected type, if necessary (12) When in mode EXPRmode, convert E to { E; () } if expected type is scala.Unit. (13) When in mode EXPRmode, apply AnnotationChecker conversion if expected type is annotated. (14) When in mode EXPRmode, do SAM conversion (15) When in mode EXPRmode, apply a view If all this fails, error

Note: the original tree parameter is for re-typing implicit method invocations (see below) and should not be used otherwise. TODO: can it be replaced with a tree attachment?

Try to apply an implicit conversion to qual to that it contains a method name which can be applied to arguments args with expected type pt. If pt is defined, there is a fallback to try again with pt = ?. This helps avoiding propagating result information too far and solves #1756. If no conversion is found, return qual unchanged.

Try to apply an implicit conversion to qual so that it contains a method name. If that's ambiguous try taking arguments into account using adaptToArguments.

Try to apply an implicit conversion to qual to that it contains a member name of arbitrary type. If no conversion is found, return qual unchanged.

Analyze the super constructor call to record information used later to compute parameter aliases

Find implicit arguments and pass them to given tree.

Overridden to false in scaladoc and/or interactive.

Check that tpt refers to a non-refinement class type

Check whether feature given by featureTrait is enabled. If it is not, issue an error or a warning depending on whether the feature is required.

Check if a structurally defined method violates implementation restrictions. A method cannot be called if it is a non-private member of a refinement type and if its parameter's types are any of:

• the self-type of the refinement
• a type member of the refinement
• an abstract type declared outside of the refinement.
• an instance of a value class Furthermore, the result type may not be a value class either

Check that type tp is not a subtype of itself.

Check that tpt refers to a class type with a stable prefix.

The typer for an expression, depending on where we are. If we are before a superclass call, this is a typer over a constructor context; otherwise it is the current typer.

Returns Some(msg) if the given tree is untyped apparently due to a cyclic reference, and None otherwise.

In order to override this in the TreeCheckers Typer so synthetics aren't re-added all the time, it is exposed here the module/class typing methods go through it. ...but it turns out it's also the ideal spot for namer/typer coordination for the tricky method synthesis scenarios, so we'll make it that.

Synthesize and type check the implementation of a type with a Single Abstract Method.

Based on a type checked Function node { (p1: T1, ..., pN: TN) => body } : S where S is the expected type that defines a single abstract method (call it apply for the example), that has signature (p1: T1', ..., pN: TN'): T', synthesize the instantiation of the following anonymous class

new S { def apply$body(p1: T1, ..., pN: TN): T = body def apply(p1: T1', ..., pN: TN'): T' = apply$body(p1,..., pN) }

The apply method is identified by the argument sam; S corresponds to the argument pt, If pt is not fully defined, we derive samClassTpFullyDefined by inferring any unknown type parameters.

The types T1' ... TN' and T' are derived from the method signature of the sam method, as seen from the fully defined samClassTpFullyDefined.

The function's body is put in a (static) method in the class definition to enforce scoping. S's members should not be in scope in body. (Putting it in the block outside the class runs into implementation problems described below)

The restriction on implicit arguments (neither S's constructor, nor sam may take an implicit argument list), is to keep the implementation of type inference (the computation of samClassTpFullyDefined) simple.

Impl notes:

• fun has a FunctionType, but the expected type pt is some SAM type -- let's remedy that
• fun is fully attributed, so we'll have to wrangle some symbols into shape (owner change, vparam syms)
• after experimentation, it works best to type check function literals fully first and then adapt to a sam type, as opposed to a sam-specific code paths earlier on in type checking (in typedFunction). For one, we want to emit the same bytecode regardless of whether the expected function type is a built-in FunctionN or some SAM type

Infer an implicit conversion (view) between two types.

If the expected type is Unit: try instantiating type arguments with expected type Unit, but if that fails, try again with pt = WildcardType and discard the expression.

A symbol is stale if it is toplevel, to be loaded from a classfile, and the classfile is produced from a sourcefile which is compiled in the current run.

The typer for a label definition. If this is part of a template we first have to enter the label definition.

This file will be the death of me.

The member with given name of given qualifier type

Translate selection that does not typecheck according to the normal rules into a selectDynamic/applyDynamic.

foo.method("blah") ~~> foo.applyDynamic("method")("blah") foo.method(x = "blah") ~~> foo.applyDynamicNamed("method")(("x", "blah")) foo.varia = 10 ~~> foo.updateDynamic("varia")(10) foo.field ~~> foo.selectDynamic("field") foo.arr(10) = 13 ~~> foo.selectDynamic("arr").update(10, 13)

what if we want foo.field == foo.selectDynamic("field") == 1, but foo.field = 10 == foo.selectDynamic("field").update(10) == () what would the signature for selectDynamic be? (hint: it needs to depend on whether an update call is coming or not)

need to distinguish selectDynamic and applyDynamic somehow: the former must return the selected value, the latter must accept an apply or an update

• could have only selectDynamic and pass it a boolean whether more is to come, so that it can either return the bare value or something that can handle the apply/update HOWEVER that makes it hard to return unrelated values for the two cases --> selectDynamic's return type is now dependent on the boolean flag whether more is to come
• simplest solution: have two method calls

Does function need to be instantiated, because a missing parameter in an argument closure overlaps with an uninstantiated formal?

Compute an existential type from raw hidden symbols syms and type tp

convert local symbols and skolems to existentials

The qualifying class of a this or super with prefix qual. packageOk is equal false when qualifying class symbol

Is symbol defined and not stale?

Report a type error.

Finds in scope or materializes a ClassTag. Should be used instead of ClassManifest every time compiler needs to persist an erasure.

Once upon a time, we had an ErasureTag which was to ClassTag the same that WeakTypeTag is for TypeTag. However we found out that we don't really need this concept, so it got removed.

Finds in scope or materializes an WeakTypeTag (if concrete is false) or a TypeTag (if concrete is true).

For flatMapping a list of trees when you want the DocDefs and Annotated to be transparent.

Convert a SAM type to the corresponding FunctionType, extrapolating BoundedWildcardTypes in the process (no type precision is lost by the extrapolation, but this facilitates dealing with the types arising from Java's use-site variance).

Post-process an identifier or selection node, performing the following:

1. Check that non-function pattern expressions are stable (ignoring volatility concerns -- scala/bug#6815) (and narrow the type of modules: a module reference in a pattern has type Foo.type, not "object Foo") 2. Check that packages and static modules are not used as values 3. Turn tree type into stable type if possible and required by context. 4. Give getClass calls a more precise type based on the type of the target of the call.

synthesize and type check a PartialFunction implementation based on the match in tree

param => sel match { cases } becomes:

new AbstractPartialFunction[$argTp, $matchResTp] { def applyOrElse[A1 <: $argTp, B1 >: $matchResTp]($param: A1, default: A1 => B1): B1 = $selector match { $cases } def isDefinedAt(x: $argTp): Boolean = $selector match { $casesTrue } }

TODO: it would be nicer to generate the tree specified above at once and type it as a whole, there are two gotchas:

• matchResTp may not be known until we've typed the match (can only use resTp when it's fully defined),
  • if we typed the match in isolation first, you'd know its result type, but would have to re-jig the owner structure
  • could we use a type variable for matchResTp and backpatch it?
• occurrences of this in cases or sel must resolve to the this of the class originally enclosing the match, not of the anonymous partial function subclass

an alternative TODO: add partial function AST node or equivalent and get rid of this synthesis --> do everything in uncurry (or later) however, note that pattern matching codegen is designed to run *before* uncurry

Types expression tree with given prototype pt.

Types expression or definition tree.

Convert an annotation constructor call into an AnnotationInfo.

Types a higher-kinded type tree -- pt denotes the expected kind and must be one of Kind.WildCard and Kind.FromParams

Remove definition annotations from modifiers (they have been saved into the symbol's annotations in the type completer / namer)

However reification does need annotation definitions to proceed. Unfortunately, AnnotationInfo doesn't provide enough info to reify it in general case. The biggest problem is with the "atp: Type" field, which cannot be reified in some situations that involve locally defined annotations. See more about that in Reifiers.scala.

That's why the original tree gets saved into original field of AnnotationInfo (happens elsewhere). The field doesn't get pickled/unpickled and exists only during a single compilation run. This simultaneously allows us to reify annotations and to preserve backward compatibility.

Types function part of an application

Types a pattern with prototype pt

Types qualifier tree of a select node. E.g. is tree occurs in a context like tree.m.

Types qualifier tree of a select node. E.g. is tree occurs in a context like tree.m.

Check that inner classes do not inherit from Annotation

Types a (fully parameterized) type tree

Types a (fully parameterized) type tree

Types a type constructor tree used in a new or supertype

Check that

• all parents are class types,
• first parent class is not a mixin; following classes are mixins,
• final classes are not inherited,

- sealed classes are only inherited by classes which are nested within definition of base class, or that occur within same statement sequence,

• self-type of current class is a subtype of self-type of each parent class.
• no two parents define same symbol.