| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Names with internal $'s are entered in package scopes only if
- we look for a name with internal $'s.
- we want to know all the members of a package scope
This optimization seems to be fairly effective. The typical range
of package scopes that need $-names is between 0 and 20%. The optimization
seems to improve execution time of all unit tests by about 3%.
Also. drop the inheritance from Iterable to Scope. The reason
is that we now need a context parameter for toList and
other Iterable operations which makes them impossible to
fit into the Iterable framework.
|
| | |
|
| | |
|
| |\
| |
| | |
Tailrec for derivesFrom/lookupRefined/classSymbol/classSymbols
|
| | | |
|
| |/
|
|
|
| |
To allow for dependencies between method type parameters, construct MethodTypes
from a closure that maps the currently constructed MethodType to its parameter types.
|
| |
|
|
|
|
|
|
|
|
|
| |
It turns out that we simply cannot do reliable outer path
computation that fills in the right hand sides of this-proxies
from the types of these proxies. As-seen-from logic can mangle
the types of proxies enough to scramble the necessary information.
What we now do instead is simply count: We record the number
of outer accesses to an outer this in inlineable code, and do the same number
of outer accesses when computing the proxy.
|
| |
|
|
|
|
|
| |
Interesting that the tests pass even if we always assume outOfContext = true.
So this raises the question why have a flag? It's just that I am not sure the
`outOfContext` behavior is correct in all cases. So I prefer to be conservative
here.
|
| |
|
|
|
|
|
|
|
|
| |
The new situation in the test was that outer of the inlined method
was `A` but it's as seen from type is a subtype `B`.
We need two fixes:
- Ignore outerSelects in TreeChecker. These are treated as having fixed symbols.
- Adapt the outer-path logic to deal with code that's moved to another context.
|
| | |
|
| |
|
|
|
| |
When computing the outer path, we need to be careful to dealias before erasure,
even if the outer path is demanded during erasure. Otherwise we lose prefixes.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we don't generate `outer` for the anonymous class `new Inner2 {}`.
This is incorrect, as `Inner2 {}` extends `A.Inner`, which requires an outer.
trait A {
val a = "a"
trait Inner {
def f = println(a)
def h = 3
}
}
trait B extends A {
trait Inner2 extends Inner
new Inner2 {}
}
|
| | |
|
| |\
| |
| | |
Fix #1755: Make sure references in outer args are accessible
|
| | |
| |
| |
| |
| |
| |
| | |
Needed a fixup action in ExplicitOuter to avoid references to
module's This from outside their scope.
The problem is fixed, but I wish I understood better the root cause.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Some outer accessors were defined at phase explicitOuter,
but were entered into the scope of their enclosing class only
at phase explicitOuter + 1. This turned them to stale symbols
when trying to access them at a later run, because at their
initially valid phase they were not found as members of
their owner.
|
| |/
|
|
|
|
| |
We confused the enclosing class (which skips the current class in super
call contexts) and the lexically enclosing class in three locations
that all had to do with the start of an outer path.
|
| |
|
