Defines the interface of the incremental compiler hiding implementation details.
Utility methods for creating (source|binary) class names for a Symbol.
This is the entry point for the compiler bridge (implementation of CompilerInterface)
Extracts dependency information from each compilation unit.
Extracts full (including private members) API representation out of Symbols and Types.
Extracts full (including private members) API representation out of Symbols and Types.
API for each class is extracted separately. Inner classes are represented as an empty (without members) member of the outer class and as a separate class with full API representation. For example:
class A { class B { def foo: Int = 123 } }
Is represented as:
// className = A class A { class B } // className = A.B class A.B { def foo: Int }
Each compilation unit should be processed by a fresh instance of this class.
NOTE: This class extract *full* API representation. In most of other places in the incremental compiler, only non-private (accessible from other compilation units) members are relevant. Other parts of the incremental compiler filter out private definitions before processing API structures. Check SameAPI for an example.
Extracts simple names used in given compilation unit.
Extracts simple names used in given compilation unit.
Extracts simple (unqualified) names mentioned in given in non-definition position by collecting all symbols associated with non-definition trees and extracting names from all collected symbols. Also extract the names of the types of non-definition trees (see source-dependencies/types-in-used-names-* and source-dependencies/as-seen-from-* for examples where this is required).
If given symbol is mentioned both in definition and in non-definition position (e.g. in member selection) then that symbol is collected. It means that names of symbols defined and used in the same compilation unit are extracted. We've considered not extracting names of those symbols as an optimization strategy. It turned out that this is not correct. Check https://github.com/gkossakowski/sbt/issues/3 for an example of scenario where it matters.
All extracted names are returned in _decoded_ form. This way we stay consistent with the rest of incremental compiler which works with names in decoded form.
Names mentioned in Import nodes are handled properly but require some special logic for two reasons:
termSymbol
of Import nodes point to the symbol of the prefix it imports from
(not the actual members that we import, that are represented as names).
2. ImportSelector is not subtype of Tree therefore is not processed by Tree.foreach
.Another type of tree nodes that requires special handling is TypeTree. TypeTree nodes has a little bit odd representation:
The tree walking algorithm walks into TypeTree.original explicitly.
This is a utility class that provides a set of functions that are used to implement straight to jar compilation.
This is a utility class that provides a set of functions that are used to implement straight to jar compilation.
sbt.internal.inc.JarUtils
is an object that has similar purpose and
duplicates some of the code, as it is difficult to share it. Any change
in the logic of this file must be applied to the other JarUtils
too!
A memoized lookup of an enclosing non local class.
A memoized lookup of an enclosing non local class.
Let's consider an example of an owner chain:
pkg1 <- pkg2 <- class A <- object B <- class C <- def foo <- class Foo <- class Bar
For an object, we work with its moduleClass
so we can refer to everything as classes.
Classes A, B, C are non local so they are mapped to themselves. Classes Foo and Bar are local because
they are defined within method foo
.
Let's define non local class more precisely. A non local class is a class that is owned by either a package or another non local class. This gives rise to a recursive definition of a non local class that is used in the implementation of the mapping.
Thanks to memoization, the amortized cost of a lookup is O(1). We amortize over lookups of all class symbols in the current compilation run.
Additionally, you can query whether a given class is local. Check isLocal
's documentation.
Contains utility methods for looking up class files corresponding to Symbols.
Defines the implementation of Zinc with all its corresponding phases.
Defines compatibility utils for ZincCompiler.
Extracts dependency information from each compilation unit.
This phase detects all the dependencies both at the term and type level.
When dependency symbol is processed, it is mapped back to either source file where it's defined in (if it's available in current compilation run) or classpath entry where it originates from. The Symbol -> Classfile mapping is implemented by LocateClassFile that we inherit from.