diff options
author | Jason Zaugg <jzaugg@gmail.com> | 2013-10-29 16:04:17 +0100 |
---|---|---|
committer | Jason Zaugg <jzaugg@gmail.com> | 2013-11-08 08:25:18 +0100 |
commit | a5127a8392fd2a0bce9b3ced302b4ebe1a80bc65 (patch) | |
tree | 4d52b8ed7dd8fcfb10d4bef41198ffe6ecc7cfe6 /src/build/bnd | |
parent | 3dba9932fcc79ce0ea6f7c9282320c14c95d133f (diff) | |
download | scala-a5127a8392fd2a0bce9b3ced302b4ebe1a80bc65.tar.gz scala-a5127a8392fd2a0bce9b3ced302b4ebe1a80bc65.tar.bz2 scala-a5127a8392fd2a0bce9b3ced302b4ebe1a80bc65.zip |
SI-7678 Don't cache member symbols of TypeTags in Definitions.
It we can only safely use vals in Definitions for top-level symbols.
Otherwise, when the IDE switches to loading the symbol from source,
we can hold on to a stale symbol, which in turn impedes implicit
materialization of TypeTags.
This commit moves (most) of the accessors for member symbols
into RunDefinitions, and changes calling code accordingly.
This is a win for presentation compiler correctness, and
might even shave of a few cycles.
In a few cases, I have had to leave a `def` to a member symbol
in Definitions so we can get to it from the SymbolTable cake,
which doesn't see RunDefinitions.
The macro FastTrack facility now correctly recreates the mapping
from Symbol to macro implementation each run, using a new facility
in perRunCaches to create a run-indexed cache.
The enclosed test recreates the situation reported in the ticket,
in which TypeTags.scala is loaded from source.
Diffstat (limited to 'src/build/bnd')
0 files changed, 0 insertions, 0 deletions