sbt/interface/src/main/java/xsbti/AnalysisCallback.java

46 lines
2.5 KiB
Java
Raw Normal View History

/* sbt -- Simple Build Tool
* Copyright 2008, 2009 Mark Harrah
*/
package xsbti;
import java.io.File;
public interface AnalysisCallback
{
/** Called to indicate that the source file <code>source</code> depends on the source file
* <code>dependsOn</code>. Note that only source files included in the current compilation will
* passed to this method. Dependencies on classes generated by sources not in the current compilation will
* be passed as class dependencies to the classDependency method.
* If <code>publicInherited</code> is true, this dependency is a result of inheritance by a
* template accessible outside of the source file. */
public void sourceDependency(File dependsOn, File source, boolean publicInherited);
/** Called to indicate that the source file <code>source</code> depends on the top-level
* class named <code>name</code> from class or jar file <code>binary</code>.
* If <code>publicInherited</code> is true, this dependency is a result of inheritance by a
* template accessible outside of the source file. */
public void binaryDependency(File binary, String name, File source, boolean publicInherited);
/** Called to indicate that the source file <code>source</code> produces a class file at
* <code>module</code> contain class <code>name</code>.*/
public void generatedClass(File source, File module, String name);
/** Called when the public API of a source file is extracted. */
public void api(File sourceFile, xsbti.api.SourceAPI source);
public void usedName(File sourceFile, String names);
/** Provides problems discovered during compilation. These may be reported (logged) or unreported.
* Unreported problems are usually unreported because reporting was not enabled via a command line switch. */
public void problem(String what, Position pos, String msg, Severity severity, boolean reported);
Extract source code dependencies by tree walking. Previously incremental compiler was extracting source code dependencies by inspecting `CompilationUnit.depends` set. This set is constructed by Scala compiler and it contains all symbols that given compilation unit refers or even saw (in case of implicit search). There are a few problems with this approach: * The contract for `CompilationUnit.depend` is not clearly defined in Scala compiler and there are no tests around it. Read: it's not an official, maintained API. * Improvements to incremental compiler require more context information about given dependency. For example, we want to distinguish between dependency on a class when you just select members from it or inherit from it. The other example is that we might want to know dependencies of a given class instead of the whole compilation unit to make the invalidation logic more precise. That led to the idea of pushing dependency extracting logic to incremental compiler side so it can evolve indepedently from Scala compiler releases and can be refined as needed. We extract dependencies of a compilation unit by walking a type-checked tree and gathering symbols attached to them. Specifically, the tree walk is implemented as a separate phase that runs after pickler and extracts symbols from following tree nodes: * `Import` so we can track dependencies on unused imports * `Select` which is used for selecting all terms * `Ident` used for referring to local terms, package-local terms and top-level packages * `TypeTree` which is used for referring to all types Note that we do not extract just a single symbol assigned to `TypeTree` node because it might represent a complex type that mentions several symbols. We collect all those symbols by traversing the type with CollectTypeTraverser. The implementation of the traverser is inspired by `CollectTypeCollector` from Scala 2.10. The `source-dependencies/typeref-only` test covers a scenario where the dependency is introduced through a TypeRef only.
2013-11-19 21:16:06 +01:00
/**
* Determines whether method calls through this interface should be interpreted as serving
* name hashing algorithm needs in given compiler run.
*
* In particular, it indicates whether member reference and inheritance dependencies should be
* extracted.
Extract source code dependencies by tree walking. Previously incremental compiler was extracting source code dependencies by inspecting `CompilationUnit.depends` set. This set is constructed by Scala compiler and it contains all symbols that given compilation unit refers or even saw (in case of implicit search). There are a few problems with this approach: * The contract for `CompilationUnit.depend` is not clearly defined in Scala compiler and there are no tests around it. Read: it's not an official, maintained API. * Improvements to incremental compiler require more context information about given dependency. For example, we want to distinguish between dependency on a class when you just select members from it or inherit from it. The other example is that we might want to know dependencies of a given class instead of the whole compilation unit to make the invalidation logic more precise. That led to the idea of pushing dependency extracting logic to incremental compiler side so it can evolve indepedently from Scala compiler releases and can be refined as needed. We extract dependencies of a compilation unit by walking a type-checked tree and gathering symbols attached to them. Specifically, the tree walk is implemented as a separate phase that runs after pickler and extracts symbols from following tree nodes: * `Import` so we can track dependencies on unused imports * `Select` which is used for selecting all terms * `Ident` used for referring to local terms, package-local terms and top-level packages * `TypeTree` which is used for referring to all types Note that we do not extract just a single symbol assigned to `TypeTree` node because it might represent a complex type that mentions several symbols. We collect all those symbols by traversing the type with CollectTypeTraverser. The implementation of the traverser is inspired by `CollectTypeCollector` from Scala 2.10. The `source-dependencies/typeref-only` test covers a scenario where the dependency is introduced through a TypeRef only.
2013-11-19 21:16:06 +01:00
*
* As the signature suggests, this method's implementation is meant to be side-effect free. It's added
* to AnalysisCallback because it indicates how other callback calls should be interpreted by both
* implementation of AnalysisCallback and it's clients.
*
* NOTE: This method is an implementation detail and can be removed at any point without deprecation.
* Do not depend on it, please.
*/
public boolean nameHashing();
}