| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The change in question broke the following pattern, commonly used in name based pattern matching:
```scala
object ProdEmpty {
def _1: Int = ???
def _2: String = ???
def isEmpty = true
def get = this
}
```
This type define both `_1` and `get` + `isEmpty` (but is not <: Product). After #1938, `ProdEmpty` became eligibles for both product and name based pattern. Because "in case of ambiguities, *Product Pattern* is preferred over *Name Based Pattern*", isEmpty wouldn't be used, breaking the scalac semantics.
|
|\
| |
| | |
Change case class desugaring and decouple Products and name-based-pattern-matching
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Product pattern use to:
- have a `<: Product` requirement
- compute the arity of a pattern by looking at `N` in a `ProductN` superclass.
This commit changes `<: Product`, instead we look for a `_1` member. The arity is determined by inspecting `_1` to `_N` members instead.
---
Here another attempt to formalize Dotty's pattern-matching (base on #1805). This covers the *Extractor Patterns* [section of the spec](https://www.scala-lang.org/files/archive/spec/2.12/08-pattern-matching.html#extractor-patterns). Dotty support 4 different extractor patterns: Boolean Pattern, Product Pattern, Seq Pattern and Name Based Pattern.
Boolean Pattern
- Extractor defines `def unapply(x: T): Boolean`
- Pattern-matching on exactly `0` patterns
Product Pattern
- Extractor defines `def unapply(x: T): U`
- `N > 0` is the maximum number of consecutive (parameterless `def` or `val`) `_1: P1` ... `_N: PN` members in `U`
- Pattern-matching on exactly `N` patterns with types `P1, P2, ..., PN`
Seq Pattern
- Extractor defines `def unapplySeq(x: T): U`
- `U` has (parameterless `def` or `val`) members `isEmpty: Boolean` and `get: S`
- `S <: Seq[V]`
- Pattern-matching on any number of pattern with types `V, V, ..., V`
Name Based Pattern
- Extractor defines `def unapply(x: T): U`
- `U` has (parameterless `def` or `val`) members `isEmpty: Boolean` and `get: S`
- If there is exactly `1` pattern, pattern-matching on `1` pattern with type `S`
- Otherwise fallback to Product Pattern on type `U`
In case of ambiguities, *Product Pattern* is preferred over *Name Based Pattern*.
|
| | |
|
| |
| |
| |
| |
| |
| | |
Since we now have separate package-scopes, it's easier to have
them take into account the special role played by the scala package.
So we can drop the funky logic of `makeScalaSpecial`.
|
| |
| |
| |
| | |
Prevviously they were actually unused.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Drop Seq implementation of name. This implementation
was always problematic because it entailed potentially
very costly conversions to toSimpleName. We now have
better control over when we convert a name to a simple
name.
|
|/ |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
MethodTypes have paramTypes whereas PolyTypes have paramBounds.
We now harmonize by alling both paramInfos, and parameterizing
types that will become common to both.
|
|
|
|
|
|
|
|
|
|
| |
This leads to a slight overall simplification, harmonizes pickle
format with internal representation, and makes MethodTypes and
PolyTypes more similar to each other.
I believe the change is useful as it is, but in particular it is
a useful step for an eventual unification of MethodTypes and
PolyTypes.
|
| |
|
|\
| |
| | |
Fix type inference for HLists and HMaps
|
| |
| |
| |
| |
| | |
Need to use fresh PolyParams instead of WildcardTypes
if constraint is committable.
|
| |
| |
| |
| |
| |
| | |
Now only Scala2 mode treats Function1's as implicit conversions. Instead we introduce
a new subclass ImplicitConverter of Function1, instances of which are turned into
implicit conversions.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The new test `falseView.scala` shows the problem. We might create
an implicit value of some type that happens to be a subtype of Function1.
We might now expect that this gives us an implicit conversion, this
is most often unintended and surprising.
See the comment in Implicits#discardForView for a discussion why
we picked the particular scheme implemented here.
|
|/ |
|
|
|
|
| |
Note that it is never used and the same method exists in transform.TreeGen
|
|\
| |
| | |
Fix #1747: Improve error message for Scala/Java type mismatch
|
| |
| |
| |
| |
| | |
We used to "fill-in" with zeroes if variances were missing. I now
think that;'s too error-prone. Better define all variances explicitly.
|
|\ \
| | |
| | | |
Factor out logic for scala functions.
|
| |/
| |
| |
| |
| |
| |
| |
| | |
* Add `isSyntheticFunction` checks for synthetic functions such as FuntionN
for N > 22 and ImplicitFunctionN for N >= 0.
* Add `erasedFunctionClass` to get the erased verion of synthetic functions.
* Change the semantics of `isFunctionClass` to return true if it is any kind of
FunctionN or ImplicitFunctionN.
|
|/
|
|
|
|
| |
This is a gross hack to support the need for a $scope
binding when XML literals are created. It should go away
once we phase out XML literals. A library-based
solution should use implicits instead.
|
|\
| |
| | |
Fix #1501 - Check trait inheritance condition
|
| |
| |
| |
| | |
It's java.io, not java.lang.
|
|/
|
|
| |
This commit extends the fix done in #1920 to implicit closures.
|
|\
| |
| | |
Fix #1915 Synthetic function traits need NoInits flag
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When compiled from Scala2 that knowledge was lost. Normally that
would be not a problem (e.g. the same thing happens for Function0-22).
But FunctionXXL is special in that it is inherited only after erasure.
Since `augmentScala2Trait` runs before erasure, it is having no effect
on FunctionXXL itself when running on classes that inherit function types of
large arities. Therefore, FunctionXXL is missing an implementation class
at phase Mixin, which means that the supercall logic which rewires
super.<init> to implementation class init cannot work. This leaves us
with a super.<init> to FunctionXXL in `i1915.scala`.
The fix is to always know that `FunctionXXL` has no init method, so
no super.<init> will be generated for it.
|
| |
| |
| |
| | |
Fixes #1915.
|
|\ \
| |/
|/| |
Implement structural type member access
|
| | |
|
| |
| |
| |
| |
| | |
Use base types instead of implicits. This is more robust
in the presence of type abstraction.
|
| |
| |
| |
| | |
New scheme for implementing structural type member access.
|
| | |
|
|/
|
|
|
|
|
|
|
|
| |
scalac hides a root import from Predef if there is an eplicit Predef import.
We now do the same (previously we did this only if the overriding import undefined
something, using a `x => _` syntax). To avoid cycles and races one had to be very careful
not to force import symbols too early, so we now compare the name before the symbol proper.
All this is likely temporary - the comment of ImportInfo#unimported points to a different,
more systematic solution.
|
| |
|
| |
|
|
|
|
|
| |
When the expected type is an implicit function, create an
implicit closure to match it.
|
|
|
|
|
|
|
|
|
| |
Also: show implicit function types correctly.
Also: refine applications of implicit funcitons
- don't do it for closure trees
- don't do it after typer.
|
| |
|
|
|
|
| |
These are always synthetic; generated on demand.
|
| |
|
|
|
|
| |
This implements the rules laid down in #1805.
|
|
|
|
| |
New implementation following the scheme outlined in #1790.
|
|\
| |
| | |
Drop function 22 limit
|
| | |
|