Extract the api after picklers, since that way we see the same symbol
information/structure irrespective of whether we were typechecking
from source / unpickling previously compiled classes.
Previously, the apiExtractor phase ran after typer.
Since this fix is hard to verify with a test (it's based on the
conceptual argument above, and anecdotal evidence of incremental
compilation of a big codebase), we're providing a way to restore the
old behaviour: run sbt with -Dsbt.api.phase=typer.
This fixes#609.
goal:
a representation of a type reference to a refinement class that's stable
across compilation runs (and thus insensitive to typing from source or
unpickling from bytecode)
problem:
the current representation, which corresponds to the owner chain of the
refinement:
1. is affected by pickling, so typing from source or using unpickled
symbols give different results (because the unpickler "localizes"
owners -- this could be fixed in the compiler in the long term)
2. can't distinguish multiple refinements in the same owner (this is
a limitation of SBT's internal representation and cannot be fixed in
the compiler)
solution:
expand the reference to the corresponding refinement type: doing that
recursively may not terminate, but we can deal with that by
approximating recursive references (all we care about is being sound for
recompilation: recompile iff a dependency changes, and this will happen
as long as we have one unrolling of the reference to the refinement)
* must start with val, lazy val, or def (no modifiers currently)
* visible only within the same .sbt file
* multiple definitions allowed without being separated by blank lines
* no blank lines allowed within a definition
Problems:
1. Without a message, users don't find 'last'
2. Showing a message for every error clutters output.
This tries to address these issues by:
1. Only showing the message when other feedback has not been provided and
'last' would not usually be helpful. This will require ongoing tweaking.
For now, all commands except 'compile' display the message. 'update' could
omit the message as well, but perhaps knowing about 'last' might be
useful there.
2. Including the exact command to show the output:
last test:compile
and not just
last <task>
3. Highlighting the command in blue for visibility as an experiment.
Review by @ijuma and @retronym, please.