NoContext

The current compilation unit

The compiler callback implementation, or null if no callback will be called.

Is the debug option set?

Either the current scope, or, if the current context owner is a class, the declarations of the current class.

Does current phase use an erased types interpretation?

Is the explicit nulls option set?

The context of expression expr seen as a member of a statement sequence

A fresh clone of this context embedded in this context.

A fresh clone of this context embedded in the specified outer context.

AbstractFile with given path, memoized

AbstraFile with given path name, memoized

SourceFile with given path, memoized

SourceFile with given path name, memoized

Sourcefile corresponding to given abstract file, memoized

A new context that summarizes an import statement

The currently active import info

Is current phase after FrontEnd?

Is this a context for the members of a class definition?

Is this a context that introduces an import clause?

Is this a context for typechecking an inlined body?

Are we in a Java compilation unit?

Is this a context that introduces a non-empty scope?

The paths currently known to be not null

All outer contexts, ending in base.initialCtx and then NoContext

A function creating a printer

The current plain printer

The current compiler-run profiler

The current reporter

The current compiler-run

The sbt callback implementation if we are run from sbt, null otherwise

The current settings values

The context for a supercall. This context is used for elaborating the parents of a class and their arguments. The context is computed from the current class context. It has

• as owner: The primary constructor of the class
• as outer context: The context enclosing the class context
• as scope: The parameter accessors in the class context

The reasons for this peculiar choice of attributes are as follows:

• The constructor must be the owner, because that's where any local methods or closures should go.
• The context may not see any class members (inherited or defined), and should instead see definitions defined in the outer context which might be shadowed by such class members. That's why the outer context must be the outer context of the class.
• At the same time the context should see the parameter accessors of the current class, that's why they get added to the local scope. An alternative would have been to have the context see the constructor parameters instead, but then we'd need a final substitution step from constructor parameters to class parameter accessors.

The context for the arguments of a this(...) constructor call. The context is computed from the local auxiliary constructor context. It has

• as owner: The auxiliary constructor
• as outer context: The context enclosing the enclosing class context
• as scope: The parameters of the auxiliary constructor.

The current type assigner or typer

Should use colors when printing?

Is the verbose option set?

The new implicit references that are introduced by this scope