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.
This represents a sketch of the idea that we can abstract over details
of a specific dependency kind. The goal would that only a few
implementations of methods in incremental would be sensitive to specific
dependency kind:
1. Dependency extraction logic
2. Implementation of Relations which adds dependencies to specific
relations (or abstract over specific relations)
3. Invalidation algorithm (Incremental.scala) which has different
of each kind of dependency
4. TextAnalysisFormat
In particular, adding a new dependency kind would not affect signatures
of existing methods.
What needs to be done:
- finish refactoring so the code compiles again and previous semantics
are preserved
- introduce deprecated overloads that preserve old method signatures
(this is required for preserving binary compatibility)
The previous implementation of TextAnalysisFormat contained the list
of all the existing relations that sbt knew of, and used this
information to write to and read from the disk the persisted analyses.
In this knew implementation, TextAnalysisFormat gets from the
Relations object what are the existing relations, and then persists
them to disk.
The previous situation was not optimal since it meant that, in order
to add a new dependency kind, one had to modify both the Relations
and TextAnalysisFormat.
Using this new implementation, no change to TextAnalysisFormat is
required whenever a new dependency kind is added.
In some cases, expanded macros report that their original tree and
its expansion are the same, thus creating a cyclic chain. This chain
may then produce a SOE during dependencies or used names extraction.
This kind of problem was already reported in sbt/sbt#1237 and
sbt/sbt#1408. Unfortunately, the fix that was applied to the
dependencies extraction part was not sufficient.
Mark test 'source-dependencies/macro' as passing
Fixes#1544
The issue is that when you manually set a ScalaInstance, i.e. not one from Ivy, the
classpath which is returned for any given configuration ONLY uses Ivy. This means that
the legitimate Scala JAR files that need to be on the classpath are missing from the list.
For some reason, the way we instantiate tests uses an unfiltered classloader against the
ScalaInstance, *BUT* the thread-context-classloader DOES use a filtered instance by
classpath. This add the hook into the TestFramework runner creation so that
the classpath accurately reflects the jars needed.
cc @rkuhn
Fixes#1568.
This is the fallout of attempting not to leak config-file classes. Since
we DO NOT have valid incremental compiler for config-classes, we've instituted
workaround to ensure that regular incremental compilation *AND* our own
sbt loader do not hose each other. A full solution will eventually be
to find a way for .sbt files to participate in regular compilation of a
project.
For now, we fix the tracking of generated.class files throughout an sbt
"loadProjects" call, and then clean any .class files that were not
generated for a full reload. This commit just fixes
a minor tracking issue.
Fixes#1565
* Create two chains if we have inter-project resolver
- One which ensures inter-project deps are always taken
- One which will look in all "other" repositories for
dependencies and will use the "most up-to-date" -SNAPSHOT
strategy.
* No additional tests, as this would simple break every
multi-project test if it were wrong.
There is sometimes the need to use a test version of Scala that is
intended to be binary compatible with a standard release version.
At this time, due to the particular logic implemented within sbt,
a non-numeric suffix will never have the same binaryScalaVersion
of a release version ending in ".0", like for instance "2.11.0".
This commit allows developers to use as suffix any string that
begins with "-bin", for instance "2.11.0-bin-compat-test-1".
Such a suffix will have a binaryScalaVersion of "2.11", being
therefore considered binary compatible with release versions.
Those tests use the random Analysis generator that is used in the
unit tests for the subproject `incremental-compiler`.
Random Analyses are serialized and then constructed back from this
representation.
Unit tests in incremental-compiler subproject use a generator to
create random Analysis objects. This generator was unfortunately
not working properly and generated only empty Analyses (it failed
to generate any non-empty Analysis because of a bug in the `unique`
generator).
Travis CI stopped allowing long file names on its file system. We need
to explicitly set lower limit on file name length using
`-Xmax-classfile-name` Scala compiler option. We set the limit to 240
characters.
Fixes#1553
Martin Duhem
Grzegorz Kossakowski
eugene yokota
Josh Suereth
Daniel Peebles
Antonio Cunei
James Ward