Serializes CompileSetup as text instead of base64-encoded
binary-serialized object.
This is necessary so that file paths in the CompileSetup can be
rebased when porting analysis files between systems.
There's one test that starts to pass when we enable name hashing. It's
`import-class` which tests whether tracking of dependencies that arise
from imports is properly tracked. The name hashing algorithm uses different
dependency tracking compared to the old algorithm and the new dependency
extraction logic does handle import tree nodes properly so the test passes.
We "mark" the test passing by copying it and enabling the name hashing
flag in it. This is done similarly as in 940f7ff46d.
There are number of scripted tests that fail if we switch to name hashing
being enabled by default. There's no easy way to mark those tests as
pending only when name hashing flag is enabled so I decided to "mark" them
by copying those tests, enabling name hashing in each of them and mark
those copies as pending.
Here's explanation of each failing test:
* `constants` and `java-static` fail due to typer inlining constants
so we can't track dependencies properly (see SI-7173)
* `macro` fails for similar reasons as above: typer expands macros
and we can't track dependencies properly
* `struct` fails because it turns out that we need to handle structural
types in a special way both at declaration and use sites. At the moment
we handle them explicitly at declaration site so `struct-usage` passes
but `struct` fails
Provide implementation of invalidation logic that takes computed
name hashes into account. The implementation is spread amongst two
classes:
1. `IncrementalNameHashing` which implements a variant of
incremental compilation algorithm that computes modified
names and delegates to `MemberReferenceInvalidationStrategy`
when invalidating member reference dependencies
2. `MemberReferenceInvalidationStrategy` which implements the
core logic of dealing with dependencies introduced by member
reference. See documentation of that class for details.
The name hashing optimization is applied when invalidating source files
having both internal and external dependencies (in initial iteration),
check `invalidateByExternal` and `invalidateSource` methods for details.
As seen in implementation of `MemberReferenceInvalidationStrategy`
the name hashing optimization is not applied when implicit members
change.
NOTE: All functionality introduced in this commit is enabled only
when `IncOptions.nameHashing` flag is set to true.
The `source-dependencies/transitive-memberRef` test has been changed
to test name hashing variant of incremental compilation. The change
to invalidated files reflects the difference between the old and the
new algorithm.
Also, there a few new tests added that cover issues previously found
while testing name hashing algorithm and are fixed in this commit.
Each paragraph describes a single test.
Add a test case which shows that detect properly changes to type aliases
in the name hashing algorithm. See gkossakowski/sbt#6 for details.
Add test covering bug with use of symbolic names (issue
gkossakowski/sbt#5).
Add a test which covers the case where we refer to a name that is
declared in the same file. See issue gkossakowski/sbt#3 for details.
* Add new ServerMain interface
* AppProvider can now choose to load ServerMain or AppMain classes
* Explicitly document what happens if something doesn't match an
expected interface
* Improve error message on inability to load something.
* Parse new [server] section that denotes a service and is lock file
* Ability to serialize launch configurations.
* Attempt to look for active listening server via the lock file
* Forks the launcher itself to run servers from serialized launch configuration.
* Testing echo server.
* Tests to detect basic server functionality will work.
* Revamp all the documentation for the launcher, giving it its own section.
* Full documentation on launcher configuration files.
Revamp launcher documentation to be a bit more in-depth, and split bits into sections.
This is an attempt to provide a decent error message in some cases. However, paths that include
the Java path separator character are just fundamentally problematic and aren't always going to
be cleanly detected.
Add a test-case that documents current behavior of incremental
compiler when it comes to invalidating dependencies that arise
from inheritance and member references.
There are two categories of places in the code that need to refer to
`nameHashing` option:
* places where Analysis object is created so it gets proper
implementation of underlying Relations object
* places with logic that is specifically designed to be enabled by
that option
This commit covers both cases.
The 39036e7c20 introduced
`recompileOnMacroDef` option to IncOptions. However, not all necessary
logic has been changed. This commit fixes that:
* `copy` method does not forget the value of the `recompileOnMacroDef`
flag
* `productArity` has been increased to match the arity of the class
* `productElement` returns the value of `recompileOnMacroDef` flag
* `hashCode` and `equals` methods take into account value of
`recompileOnMacroDef` flag
* fix the name of the key for `recompileOnMacroDef` flag
Move implementation of the following methods from IncrementalCommon
to IncrementalDefaultImpl:
* invalidatedPackageObjects
* sameAPI
* invalidateByExternal
* allDeps
* invalidateSource
These are the methods that are expected to have different implementation
in the name hashing algorithm. Hence, we make them abstract in
IncrementalCommon so they can be implemented differently in subclasses.
Refactor the `invalidateByExternal` method to take single, external
api change. Introduce `invalidateByAllExternal` that takes all APIChanges
object.
This way `invalidateByExternal` will have an access to APIChange object
that represents changed name hashes once name hashing is merged.
This way we'll be able to have a polymorphic implementation of this
method in the future. One implementation will use the old dependency
tracking mechanism and the other will use the new one (implemented
for name hashing).
In addition to `invalidateSources` we introduce `invalidateSource`
that invalidates dependencies of a single source. This is needed
for the name hashing algorithm because its invalidation logic
depends on information about API changes of each source file
individually.
The refactoring is done in `IncrementalCommon` class so it affects
the default implementation as well. However, this refactoring does
not affect the result of invalidation in the default implementation.
Introduce an abstract `IncrementalCommon class that holds the
implementation of incremental compiler that was previously done in
`Incremental` class. Also, introduce `IncrementalDefaultImpl` that
inherits from IncrementalCommon.
This is the first step to introduce a design where most of incremental
compiler's logic lives in IncrementalCommon and we have two subclasses:
1. Default, which holds implementation specific to the old algorithm
known from sbt 0.13.0
2. NameHashing, which holds implementation specific to the name
hashing algorithm
This commit is purely a refactoring and does not change any behavior.
Both Logger and IncOptions instances were passed around Incremental class
implementation unmodified. Given the fact that entire implementation of
the class uses exactly the same values for those types it makes sense
to extract them as constructor arguments so they are accessible everywhere.
This helps reducing signatures of other methods to more essential
parameters that are more specific to given method.
Move most of the functionality from `Incremental` object to its
companion class.
This commit is a preparation for making it possible to have
two different implementation of logic in `Incremental` object.
This entailed modifying ResolutionCache and the CustomPomParser
to reflect changes to the ResolutionCacheManager interface and
DefaultExtendsDescriptor class between Ivy 2.3.0-rc1 and
2.3.0-rc2. Specifically,
1. ResolutionCacheManager now includes two additional methods
that needed implementations in ResolutionCache:
getResolvedModuleDescriptor(mrid: ModuleRevisionId) and
saveResolvedModuleDescriptor(md: ModuleDescriptor). I adapted
the implementations for these (which are expressed primarily in
terms of other interface methods) from Ivy 2.3.0's
DefaultResolutionCacheManager.
2. Instead of taking a ModuleRevisionIdentifier and a resolved
ModuleRevisionIdentifier as its first two arguments, the
DefaultExtendsDescriptor constructor now takes a
ModuleDescriptor. This was a trivial change.
Note that ResolutionCache.getResolvedModuleDescriptor does not
appear to be used by Ivy as sbt uses Ivy and there is thus no
test coverage for its implementation. Also note that the
DefaultResolutionCacheManager object created in
Update.configureResolutionCache now requires a reference to an
IvySettings object; DRCM expects this to be non-null.
This requires a Format[T] to be implicitly available at the call site and requires the task
to be referenced statically (not in a settingDyn call). References to previous task values
in the form of a ScopedKey[Task[T]] + Format[T] are collected at setting load time in the
'references' setting. These are used to know which tasks should be persisted (the ScopedKey)
and how to persist them (the Format).
When checking/delegating previous references, rules are slightly different.
A normal reference from a task t in scope s cannot refer to t in s unless
there is an earlier definition of t in s. However, a previous reference
does not have this restriction. This commit modifies validateReferenced
to allow this.
TODO: user documentation
TODO: stable selection of the Format when there are multiple .previous calls on the same task
TODO: make it usable in InputTasks, specifically Parsers
Josh Suereth
Grzegorz Kossakowski
Benjy
kenji yoshida
Dan Sanduleac
Jacek Laskowski
David Hotham
Mark Harrah
Christian Dedie
William Benton