From 40063b0009d55ed527bf1625d99a168a8faa4124 Mon Sep 17 00:00:00 2001 From: Eugene Burmako Date: Sat, 24 Nov 2012 22:32:17 +0100 Subject: refactors handling of parent types 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. --- test/files/neg/t5529.check | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) (limited to 'test/files/neg/t5529.check') diff --git a/test/files/neg/t5529.check b/test/files/neg/t5529.check index 5d2175fa79..da3f84e1ec 100644 --- a/test/files/neg/t5529.check +++ b/test/files/neg/t5529.check @@ -4,7 +4,4 @@ t5529.scala:12: error: File is already defined as class File t5529.scala:10: error: class type required but test.Test.File found sealed class Dir extends File { } ^ -t5529.scala:10: error: test.Test.File does not have a constructor - sealed class Dir extends File { } - ^ -three errors found +two errors found -- cgit v1.2.3