| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
| |
The pickling package got rather large and confusing with three
separate tasks that each had their own conventions: read JVM classfiles,
read Scala2 pickle info, read Tasty. The classes for each task are now in
separate packages.
|
| |
|
|
|
| |
These only exist if there was a pickler, and they are not unique
per CompilationUnit.
|
| |
|
|
|
|
|
| |
So far: Only one source file is recorded. Should evaluate
whether more are needed. Will programs composed from several
source files be pickled? They will certainly be generated after
inlining, but maybe all that happens after pickling?
|
| |
|
|
|
|
|
| |
If a unit has several top-level classes or object (which are not linked classes
of each other) each gets its own pickle information, which contains
any enclosing package clauses and imports and then just the top-level
class/object and its companion object.
|
| | |
|
| | |
|
| |
|
|
| |
To allow other phases to generate their info.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Objective: Avoid cycles by detecting all cases where
A <: B and B <: A
and removing those cases by unifuing A and B.
Cycles need to be avoided because they lead to deep subtype recursions.
|
| |
|
|
| |
… and cleaned up and simplified other context-reated features.
|
|
|
Some initial bug fixes.
Added -explaintypes diagnostics.
|
