The reason for instability is a bit tricky so let's unpack what the
previous code checking if there's self type declared was doing. It would
check if `thisSym` of a class is equal to a symbol representing the class.
If that's true, we know that there's no self type. If it's false, then
`thisSym` represents either a self type or a self variable. The second
(type test) was supposed to check whether the type of `thisSym` is
different from a type of the class. However, it would always yield false
because TypeRef of `thisSym` was compared to ClassInfoType of a class.
So if you had a self variable the logic would see a self type (and that's
what API representation would give you).
Now the tricky bit: `thisSym` is not pickled when it's representing just
a self variable because self variable doesn't affect other classes
referring to a class. If you looked at a type after unpickling, the
symbol equality test would yield true and we would not see self type when
just a self variable was declared.
The fix is to check equality of type refs on both side of the type equality
check. This makes the pending test passing.
Also, I added another test that checks if self types are represented in
various combinations of declaring a self variable or/and self type.
Fixes#2504.
Add a pending test that shows a problem with instability of representing
self variables. This test covers the bug described in #2504.
In order to test API representation of a class declared either in source
file or unpickled from a class file, ScalaCompilerForUnitTesting has been
extended to extract APIs from multiple compiler instances sharing a
classpath.
This commit enables control of whether a compiler instance should be reused
between compiling groups of Scala source files. Check comments in the code
for why this can be useful to control.
When concatenating the artifacts coming from two modules, we sometimes
attempted to create a default artifact from the organization and name of
the module.
However, this may fail because a module a % b "1.0" may not have an
artifact named "b.jar" (see sbt/sbt#2431).
Fixessbt/sbt#2431.
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.
eugene yokota
Martin Duhem
Grzegorz Kossakowski
Dale Wijnand
Jason Zaugg
Tim Harper
Antonio Cunei