* Split Java analyzing compile into its own class.
* MixedAnalyzingCompiler now only does the mixing
* Start moving methods around to more-final locations
* Static analyzingCompile method now constructs a MixedAnalyzingCOmpiler and delegates to incremental compile.
* IncrementalCompiler IC object now holds the actual logic to start incremental compilation (rather than AggresiveCompiler or other)
* MixedAnalyzingCompiler ONLY does anlaysis of Java/Scala code
* Moved the AnalyzingJavaCompiler into the integration library so that necessary dependencies are visible.
* Removed as many binary incompatibilities as I could find.
* Deprecating old APIs
* Attempt to construct new nomenclature that fits the design of Incremental API.
* Add as much documentation as I was comfortable writing (from my understanding of things).
* Split Java analyzing compile into its own class.
* MixedAnalyzingCompiler now only does the mixing
* Start moving methods around to more-final locations
* Static analyzingCompile method now constructs a MixedAnalyzingCOmpiler and delegates to incremental compile.
* Force CompileSetup Equiv typeclass to use Equiv relations defined locally.
* Add toString methods on many of the incremental compiler datatypes.
* Remove remaining binary compatibility issues in Defaults.scala.
* Removed as many binary incompatibilities as I could find.
* Deprecating old APIs
* Attempt to construct new nomenclature that fits the design of Incremental API.
* Add as much documentation as I was comfortable writing (from my understanding of things).
This breaks the loading/saving of the incremental compiler analysis out
into separate task, thereby providing the necessary hooks for byte code
enhancement tasks to enhance bytecode and update the analysis before the
analysis gets stored to disk.
In some cases the dependency extraction may encounter a null `TypeTree`
(eg. arguments of macro annotations that are untyped). In such cases,
we simply ignore the node.
Fixes#1593, #1655.
Since `DependencyContext` is needed in the compiler interface
subproject, it has to be defined in this same subproject.
`DependencyContext` is needed in this subproject because the
`AnalysisCallback` interface uses it.
Since `DependencyContext` is needed in the compiler interface
subproject, it has to be defined in this same subproject.
`DependencyContext` is needed in this subproject because the
`AnalysisCallback` interface uses it.
A new infrastructure to register sources and their dependencies has
been introduced in `c09a391`.
This commit brings the required modifications to `AnalysisTest`,
so that it uses it.
A new infrastructure to register sources and their dependencies has
been introduced in `c09a391`.
This commit brings the required modifications to `AnalysisCallback`,
so that it uses it.
This commit implements the abstraction over the dependency kinds and
deprecates the methods that were used to register files and their
dependencies.
Dependencies are now divided into two categories : Internal and
External dependencies. Moreover, each internal or external dependency
has a Context, which describes what introduced the dependency (for
instance, a dependency may be introduced by member reference or by
inheritance).
Dependencies must now be registered using the method `addSource` in
`Analysis` and in `Relations`. This method has the advantage of being
independent from the existing dependency contexts. That is, its
signature does not need to be modified whenever a new dependency
context is introduced.
- minigraph sha now contains extra attributes from artifacts
- artifacts are merged from different mini graphs (in some cases, this
should result to better resolution than stock ivy)
Grzegorz Kossakowski
Josh Suereth
James Roper
Martin Duhem
eugene yokota
j-keck
andrzej.jozwik@gmail.com
Kousuke Saruta
Peter Vlugter
KaiXinXiaoLei