sbt's shell provided completion only for keys that were relative to a
defined project, but didn't provide completion for keys that belong to
the build definition only.
This commit fixes this issue by defining a new kind of `Parser` (from
which completions are generated) which runs its input simultaneously on
distinct parsers. We now define a parser for project-level keys and
another parser for build-level keys. These two parsers are eventually
combined, and we get the completions of both parsers.
Fixessbt/sbt#2460
Fixes#2464 and Fixes#2465
appResolvers is a set of resolvers specified in the launcher
configuration.
This list fluctuates depending on the version of sbt, and sbt 0.13.10
meant to stabilize it by weeding out JCenter even when it includes it,
which failed when I applied the filter on the wrong list. This should
correct it.
For example, when the `--sourcepath` option is provided
and the refchecks phase compiles an annotation found
on a referenced symbol from the sourcepath.
`compileLate` assumes that all non-sentinel compiler
phases can be down cast to `GlobalPhase`.
This commit changes the two phases in SBT to extend
this instead of `Phase`. This has the knock on benefit
of simplifying the phases by letting the `GlobalPhase.run`
iterator over the list of compilation units and feed them
to us one by one.
I checked that the test case failed before making each
change.
For example, when the `--sourcepath` option is provided
and the refchecks phase compiles an annotation found
on a referenced symbol from the sourcepath.
`compileLate` assumes that all non-sentinel compiler
phases can be down cast to `GlobalPhase`.
This commit changes the two phases in SBT to extend
this instead of `Phase`. This has the knock on benefit
of simplifying the phases by letting the `GlobalPhase.run`
iterator over the list of compilation units and feed them
to us one by one.
I checked that the test case failed before making each
change.
Private vars and private vals defined in a trait impact the bytecode
generated for the implementors of these traits. The scripted test
`source-dependencies/trait-private-var` only accounted for private vars.
It now tries the same scenario both with private vars and private vals.
The previous logic was wrong and included all members of traits in their
API hash, which degraded the performance of the incremental compiler.
This commit changes this logic so that only the non-public members of
traits are included into their API hash.
Fixes#2436
It's not clear what the distinction between compiler-project and
source-dependencies scripted tests is so let's stick to the one that has
the biggest number of tests for incremental compiler.
The test shows that name hashing optimization is broken for members
defined in traits. The problem is that modification of a member of a trait
triggers change of a hash of trait's name.
The behavior covered by this test regressed in
40ebc82531
The bug is tracked in #2436.
Add a new field in `Source` that indicates whether this `Source`
represents a package object. This field is used in the incrmental
compiler to perform recompilation of package objects rather than relying
on the file name being `package.scala`.
Mark pending test `source-dependencies/package-object-name` as passing.
The convention says to place package objects in files named
`package.scala`, but this is not enforced by the scala specification.
The incremental compiler currently offers special treatment for files
whose name is `package.scala`, but it should rather care about whether a
file defines a package object or not.
This test fails because it defines a package object in a file whose name
is not `package.scala`.
It's not clear what the distinction between compiler-project and
source-dependencies scripted tests is so let's stick to the one that has
the biggest number of tests for incremental compiler.
The test shows that name hashing optimization is broken for members
defined in traits. The problem is that modification of a member of a trait
triggers change of a hash of trait's name.
The behavior covered by this test regressed in
40ebc82531
The bug is tracked in #2436.
Modify `invalidatedPackageObjects` to look for package objects that
transitively inherit from an invalidated class instead of just inheriting
directly. This is the correct behavior that should have been implemented
in the first place. The bug comes from a subtle copy&paste mistake. The old
implementation used `publicInherited` relation and new one looks identical
but uses `inheritance` relation. The difference is that `publicInherited`
was a relation that was expanded transitively along inheritance chain but
`inheritance` is not. We have to perform the transitive walk in
`IncrementalNameHashing.invalidatedPackageObjects` implementation.
Mark `pkg-self` test as passing.
Fixes#2326
To aid debugging, modify Relations.toString to include `inheritance` in
addition to already printed `memberRef` relation.
Modify it for both name hashing and old implementation.
The previous version of `pkg-self` covered scenario where a package object
inherited directly from a class that is being modified and recompiled in
subsequent steps. The #2326 shows that name hashing fails to handle
a package object that inherits indirectly from a modified class. In that
case, name hashing fails to invalidate the source file that defines the
package object.
This commit expands `pkg-self` with a class B that inherits from modified
class `A` and makes package object inherit from B. We mark that test as
pending to show that this indeed trigger the bug in name hashing.
Martin Duhem
Dale Wijnand
Eugene Yokota
Jason Zaugg
Tim Harper
Grzegorz Kossakowski
Antonio Cunei