| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
Change case class desugaring and decouple Products and name-based-pattern-matching
|
| |
| |
| |
| |
| |
| | |
- t7296 & case-class-23 are moved out of pending
- 1938 tests productElement > 23
|
|/
|
|
|
| |
A new kind of child annotation that points to the term symbol representing an
enum value.
|
| |
|
| |
|
|
|
|
|
| |
- rename utility methods
- generate utility methods also for object cases
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Support cases with type parameters that implicitly extend a non-parameterized base
without needing their own extends clause. The proposal has been updated to make clear
that this is supported.
Also address other reviewers comments.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Based on the discussion in #1970, enumeration objects now
have three public members:
- valueOf: Map[Int, E]
- withName: Map[String, E]
- values: Iterable[E]
Also, the variance of case type parameters is now
the same as in the corresponding type parameter of
the enum class.
|
|
|
|
|
|
|
|
|
|
|
| |
In an enum case like
case C() extends P1 with ... with Pn ...
apply now returns `P1 & ... & Pn`, where before
it was just P1.
Also, add to Option test.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Flags like Trait are in fact not always defined when a symbol
is created. For symbols loaded from class files, this flag, and
some other is defined only once the classfile has been loaded.
But this happens in general before the symbol is completed.
We model this distinction by separating from the `FromStartFlags` set
a new set `AfterLoadFlags` and distinguishing between the two sets
in `SymDenotations#is`.
Test case is enum-Option.scala. This erroneously complained before
that `Enum` was not a trait.
|
| |
|
|
|
|
| |
These are now implemented in scala.runtime.
|
| |
|
| |
|
| |
|
|\
| |
| | |
Make case class hashCode take class into account
|
| |\ |
|
| | |
| | |
| | |
| | | |
Also, update check file.
|
| |/
|/| |
|
|/ |
|
| |
|
| |
|
|\
| |
| | |
Fix desugaring of variable pattern leaking into API
|
| |
| |
| |
| |
| | |
This was especially bad for incremental compilation since the temporary
variable name is unstable.
|
| | |
|
|/ |
|
| |
|
|\
| |
| | |
Fix #2054
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
ParamForwarding creates the following forwarder in B:
private[this] def member: Int = super.member
Where the type for `super.member` is `TermRef(SubA, member)` and the
symbol is the `val member` in `A`.
So far this is correct, but in later phases we might call `loadDenot` on
this `TermRef` which will end up calling `asMemberOf`, which before this
commit just did:
prefix.member(name)
This is incorrect in our case because `SubA` also happens to have a
private `def member`, which means that our forwarder in B now forwards
to a private method in a superclass, this subsequently crashes in
`ExpandPrivate`.
(Note: in the bytecode, a private method cannot have the same name as an
overriden method, but this is already worked around in EnsurePrivate.)
The fix is simple: when we recompute a member, we should only look at
private members if the previous denotation was private.
|
|\ \
| | |
| | | |
Fix #1960: add test
|
| | | |
|
|/ /
| |
| |
| |
| | |
Move fixed logic to FirstTransform, where the other constant
folding operations are also done.
|
|\ \
| | |
| | | |
Fix type inference for HLists and HMaps
|
| | |
| | |
| | |
| | |
| | |
| | | |
Type inference tends to take quite different paths for non-variant
and variant data structures. Since, non-variant hmap has already exposed quite
a few problems, it's good to test it also in the covariant case.
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
Variance changes quite a few things for type inference, so
it's good to check a non-variant version as well.
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
The HLists test brought out the unsoundness of alias
rewriting in glbs which is tackled in the last commit.
|
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| |/
|/| |
|
|\ \
| |/
|/| |
Fix #2030: Don't chain implicit conversions
|
| | |
|
|\ \
| |/
|/| |
HMap test case
|