| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We allow value class constructors to be non-public, so to be regular,
we should also allow the same for the param accessor.
This commit uses the 'makeNotPrivate' machinery to ensure that
the backend can generate the requisite unboxing calls.
This commit:
- refactors the code that enforced the restrictions, improving
a few error messages and positions. The remaining restrictions
needed some rewording in light of this change.
- allows value classes to have non-public, val parameters.
private[this] / protected[this] are still disallowed as value
classes don't have a concept of `this`, and because trying to
accomdate then would complicate the implementation.
This means that `class C(x: Int) extends AnyVal` is not allowed,
the user still must write `private val x: Int` or `val x: Int`.
- Outlaw `class C()()(val x: Int) extends AnyVal` to curtail any
bugs that might lurk in such a formulation.
The tests:
- Show that the privacy is respected in the typer phase, under
joint and separate compilation. We don't want a repeat performance
of SI-6601.
- Show that code that needs compiler-generated unboxes works under
both compilation scenarios
- Checks that the remaining restrictions are enforced and well
communicated.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At the moment parser does too much w.r.t handling of parent types.
It checks whether a parent can have value arguments or not and
more importantly, it synthesizes constructors and super calls.
This approach is fundamentally incompatible with upcoming type macros.
Take for example the following two snippets of code:
`class C extends A(2)`
`class D extends A(2) with B(3)`
In the first snippet, `A` might be a type macro, therefore the super call
`A.super(2)` eagerly emitted by the parser might be meaningless. In the
second snippet parser will report an error despite that `B` might be
a type macro which expands into a trait.
Unfortunately we cannot simply augment the parser with the `isTypeMacro`
check. This is because to find out whether an identifier refers to a type
macro, one needs to perform a typecheck, which the parser cannot do.
Therefore we need a deep change in how parent types and constructors
are processed by the compiler, which is implemented in this commit.
|
|
|
|
| |
as errors. Fixed erasure scheme.
|
|
|
|
| |
enforced. Super calls and specialized still missing.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...since it works from source. The parser must be forcibly restrained
from adding a bogus constructor, but other than that it's pretty much
smooth sailing. To give an idea how smooth, if I change scala.Short like so:
trait Bippy extends Any
final class Short extends AnyVal with Bippy
Then it just works, at least until the fiction is revealed.
scala> def f(x: Bippy) = x
f: (x: Bippy)Bippy
scala> f(5)
<console>:9: error: type mismatch;
found : Int(5)
required: Bippy
f(5)
^
scala> f(5: Short)
java.lang.ClassCastException: java.lang.Short cannot be cast to scala.Bippy
at .<init>(<console>:9)
at .<clinit>(<console>)
at .<init>(<console>:11)
|
|
-- traits can extend Any, AnyRef, or AnyVal
-- classes can extend AnyRef or AnyVal but not Any.
This breaks reflection for the moment as it smuggles AnyVal so far
downstream that it's reflecting its way into bytecode (or something)
but the following test case goes five for six as anticipated.
trait Foo1 extends Any
trait Foo2 extends AnyVal
trait Foo3 extends AnyRef
class Bar1 extends Any // fail
@inline class Bar2 extends AnyVal
class Bar3 extends AnyRef
Eliminated various hijinx from definitions.
|