summaryrefslogtreecommitdiff
path: root/test/files/neg/anyval-anyref-parent.check
Commit message (Collapse)AuthorAgeFilesLines
* SI-7859 Value classes may wrap a non-public memberJason Zaugg2013-09-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* refactors handling of parent typesEugene Burmako2012-12-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* Fixes to value classes: Flags now double definitions, private constructors ↵Martin Odersky2012-03-061-3/+3
| | | | as errors. Fixed erasure scheme.
* All steps of value class proposal implemented. Most restrictions are now ↵Martin Odersky2012-02-131-3/+12
| | | | enforced. Super calls and specialized still missing.
* Removing unnecessary AnyVal code.Paul Phillips2012-02-061-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | ...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)
* Making AnyVal into a class instead of a trait.Paul Phillips2012-02-041-0/+4
-- 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.