| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
This implements the rules laid down in #1805.
|
| |
|
|
|
|
|
|
|
|
|
| |
Like all other variables, pattern-bound vars need a fully defined type. I was
thinking originally that demanding a fully defined selector type is sufficient
to ensure this, but that's not true: An outer pattern might call a polymorphic
unapply and its type variables need not be fully instantiated.
With the fix, the minimized test case from ExpandSAMs works.
|
|
|
|
|
| |
Also, make binder type of SkolemType refer to arbitrary type,
not necessarily RefinedType.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the end, this did not buy us anything. What matters is that
- we can reliably identify RefinedThis types pointing to a given
refinement type. Making sure that the `binder` field of q RefinedThis
type in a refinedInfo is always the containing refined type is good
enough for that.
- we take care to rebind RefinedThis types in isSubType. This was leaky before,
is handled now better in the new isSubType.
So, in the end, adding a level was a needless complication. Also, as a next step
we should be able to identify skolem types and RefinedThis types.
|
|
|
|
| |
Plus, RefinedThis gets a second parameter, `level`. This will replace the first one in due time.
|
| |
|
|
|
|
| |
from pr #174.
|
|
|
|
| |
And a test for this.
|
| |
|
|
|
|
| |
Now patmat passes tests but erasure fails.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
New phase ElimByName elimintaes by-name parameters. All other
occurrences of parameterless methods and ExprTypes are eliminated
in erasure.
The reason for the split like this is that it is very hard for
Nullarify to determine when to insert ()'s. The logic for this
is fragile because we need to look at previous denotations which might
not exist (before splitter) or might result from a merge
between parameterless and nullary methods. In Erasure
the same is much simpler to achieve.
|
|
|
|
|
|
|
|
|
|
| |
Problem 1: The parser did not accept them. It has to accept a "RefinedType" as an ascription,
not a "WithType" (as it did before), or even a "SimpleType" (as speced in the SyntaxSummary).
Problem 2: Annotations are always typed as expressions. The annotations in question were typed
as patterns before.
Tests in Patterns.scala and in the Dotty compiler itself.
|
|
|
|
| |
Previously, we did not strip off the => when comparing against expected type.
|
|
|