| 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.
|
| |
|
|
|
|
|
| |
Start scheme where unmangling is done by NameKinds instead of
in NameOps.
Also add namekinds for protected accessors.
|
| | |
|
| |
|
|
|
|
| |
Two benefits: (1) less code. (2) finding subtle bugs about
parameter dependent method types. By merging with PolyTypes
we are forced to take parameter dependencies into account.
|
| | |
|
| |
|
|
|
| |
- Use TypeLambda instead of PolyType.
- Further harmonize factory operations
|
| |
|
|
| |
Replace with ParamRef
|
| | |
|
| | |
|
| |
|
|
| |
Use an abstract type instead.
|
| |
|
|
| |
Trying to bring PolyTypes closer to TypeLambdas
|
| |
|
|
|
|
| |
MethodTypes have paramTypes whereas PolyTypes have paramBounds.
We now harmonize by alling both paramInfos, and parameterizing
types that will become common to both.
|
| |
|
|
|
| |
and generalize MethodParam to ParamRef, and
TypeParamInfo to ParamInfo
|
| |\
| |
| | |
Fix #2137: Create dummy companions for top-level objects without a real one
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit 57641b9c7447fa0a6f1f47352dffb4c56c560b6a.
Using `Type#select` instead of `Type#member` turned out to not help at
all in avoiding false dependencies, you can still get a symbol whose
denotation does not reallyExists. A proper fix for this issue is
contained in the next commit.
|
| |/
|
|
|
|
|
|
|
| |
Previously, every time sbt was restarted, `compile` would do a full
recompilation. This happened because sbt uses Java serialization to
persist the incremental compilation analysis, deserialization was always
silently failing because we used to serialize a class from the
dotty-compiler jar which is not on the classpath at deserialization
time. See the added comments for more details.
|
| | |
|
| |
|
|
|
| |
To allow for dependencies between method type parameters, construct MethodTypes
from a closure that maps the currently constructed MethodType to its parameter types.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The output of ExtractAPI should be stable, otherwise sbt might
incorrectly conclude that some API changed because its hash is
different, even though the source hasn't changed. This commit fixes two
cases where this might happen:
- package prefixes in NamedTypes are unstable, we already worked around this by
normalizing them, but only for classes, we now always do it.
- We use a simplified representation for `_ >: Nothing <: Any`, this is
now checked using `isDirectRef` instead of referential equality on types
since there is more than one way to represent `Nothing` and `Any`.
Both of these issues were found while compiling dotty with
`dotty-compiler-bootstrapped/compile` and making small changes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Illegal class overrides are fundamentally at odds with the way dotty
represents types and therefore can cause lots of low-level problems.
Two measures in this commit
First, we detect direct illegal class overrides on completion instead of
during RefChecks. Break the override by making the previously
overriding type private.
This fixes i1750.scala, but still fails for indirect overrides between
two unrelated outer traits/classes that are inherited by the same class or trait.
We fix this by catching the previously thrown ClassCastException
in both ExtractAPI and RefChecks.
Test case for indirect overrides is in i1750a.scala.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Type#member might return a denotation that doesn't "really exists" (as
defined by TypeAssigner#reallyExists), in some circumstance this
denotation can refer to a symbol in a class that is in the classpath but
that is not used by this file, so using addDependency on the result of
Type#member might add a false dependency. We avoid this by using
Type#select instead which will internally do the right thing.
This issue was discovered while compiling the bootstrapped projects
which would sometimes force a full recompilation for no reason.
|
| |
|
|
|
|
|
|
|
| |
This is necessary for correct incremental recompilation but is also used
by sbt to find tests to run (for junit they should be annotated @org.junit.Test).
I added an sbt scripted test to verify that JUnit now works, to run it:
$ sbt
> scripted discovery/test-discovery
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This fix the test "Extracted source dependencies from public members"
which previously failed with:
Set('G, 'E) is not equal to Set('B, 'E) (DependencySpecification.scala:34)
`H` extends `G.T[Int]` which is an alias of `B`, so the
`topLevelInheritanceDepndencies` of `H` should contain `B`, this was not
the case before because we didn't dealias before looking for the
top-level class of the dependency, so we ended up with `G`, the
top-level class in which the alias `T` is contained.
|
| |
|
