summaryrefslogtreecommitdiff
path: root/test/files
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #4047 from lrytz/delambda-method-testsLukas Rytz2014-11-077-8/+19
|\ | | | | Fix tests under -Ydelambdafy:method
| * Fix lambda names under delambdafy:method in innerClassAttribute testLukas Rytz2014-10-101-3/+3
| | | | | | | | This should have been done in 63207e1
| * Ensure delambafy:inline for anonymous function class javap testLukas Rytz2014-10-102-1/+5
| | | | | | | | https://issues.scala-lang.org/browse/SI-8898
| * Ensure closure elimination test runs under -Ydelambdafy:inlineLukas Rytz2014-10-101-1/+1
| |
| * Fix t8549 under -Ydelambdafy:methodLukas Rytz2014-10-101-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the structure of Option.class generated by delambdafy:method is slightly different. For example, lambdas declared within Option are not emitted as nested classes, so under delambdafy:method there's no inner class entry for anonfun classes. The test failed because serializing a ClassTag involves serializing an Option. Option did not have a `@SerialVersionUID`, and the classfile generated by delambdafy:method has a different value. The annotation is required on the parent class (Option) as well as the subclasses (Some / None). De-serializing a Some will fail if Option has a different SerialVersionUID. Relates to SI-8576. We should probably have more SVUID annotations in the library.
| * Update check files for -Ydelambdafy:methodLukas Rytz2014-10-102-2/+6
| | | | | | | | Should have been done in 63207e1.
* | Merge pull request #4080 from gourlaysama/wip/t8931-redundant-interfaces-2Jason Zaugg2014-11-072-0/+16
|\ \ | | | | | | SI-8931 make generic signature consistent with interface list in classfiles
| * | SI-8931 make generic signature consistent with interface list in classfilesAntoine Gourlay2014-11-052-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An optimization was introduced in 7a99c03 (SI-5278) to remove redundant interfaces from the list of implemented interfaces in the bytecode. However the same change was not propagated to the generic signature of a class, which also contains a list of direct parent classes and interfaces. The JVM does not check the well-formedness of signatures at class loading or linking (see ยง4.3.4 of jdk7 jvms), but other tools might assume the number of implemented interfaces is the same whether one asked for generic or erased interfaces. It doesn't break reflection so nobody complained, but it does show: scala> val c = classOf[Tuple1[String]] c: Class[(String,)] = class scala.Tuple1 scala> c.getInterfaces // Product is gone res0: Array[Class[_]] = Array(interface scala.Product1, interface scala.Serializable) scala> c.getGenericInterfaces // Product is back! res1: Array[java.lang.reflect.Type] = Array(scala.Product1<T1>, interface scala.Product, interface scala.Serializable) This moves the optimization to erasure, for use in emitting the generic signature, and the backend calls into it later for the list of interfaces.
* | | Merge pull request #4097 from retronym/ticket/7602Jason Zaugg2014-11-072-0/+31
|\ \ \ | | | | | | | | SI-7602 Avoid crash in LUBs with erroneous code
| * | | SI-7602 Avoid crash in LUBs with erroneous codeJason Zaugg2014-11-072-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a class contains a double defintion of a method that overrides an interface method, LUBs could run into a spot where filtering overloaded alternatives to those that match the interface method fails to resolve to a single overload, which crashes the compiler. This commit uses `filter` rather than `suchThat` to avoid the crash.
* | | | Merge pull request #4096 from retronym/ticket/7019Jason Zaugg2014-11-071-0/+10
|\ \ \ \ | | | | | | | | | | SI-7019 Fix crasher with private[this] extension methods
| * | | | SI-7019 Fix crasher with private[this] extension methodsJason Zaugg2014-11-061-0/+10
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | When we move the body of value class methods to the corresponding extension method, we typecheck a forward method that remains in the class. In order to allow access, this commit weakens the access of `private[local]` extension methods to `private`.
* | | | Merge pull request #4083 from retronym/ticket/8947Jason Zaugg2014-11-072-0/+42
|\ \ \ \ | | | | | | | | | | SI-8947 Avoid cross talk between tag materializers and reify
| * | | | SI-8947 Avoid cross talk between tag materializers and reifyJason Zaugg2014-10-302-0/+42
| | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After a macro has been expanded, the expandee are expansion are bidirectionally linked with tree attachments. Reify uses the back reference to replace the expansion with the expandee in the reified tree. It also has some special cases to replace calls to macros defined in scala-compiler.jar with `Predef.implicitly[XxxTag[T]]`. This logic lives in `Reshape`. However, the expansion of a macro may be `EmptyTree`. This is the case when a tag materializer macro fails. User defined macros could do the also expand to `EmptyTree`. In the enclosed test case, the error message that the tag materializer issued ("cannot materialize class tag for unsplicable type") is not displayed as the typechecker finds another means of making the surrounding expression typecheck. However, the macro engine attaches a backreference to the materializer macro on `EmpytyTree`! Later, when `reify` reshapes a tree, every occurance of `EmptyTree` will be replaced by a call to `implicitly`. This commit expands the domain of `CannotHaveAttrs`, which is mixed in to `EmptyTree`. It silently ignores all attempts to mutate attachments. Unlike similar code that discards mutations of its type and position, I have refrained from issuing a developer warning in this case, as to silence this I would need to go and add a special case at any places adding attachments.
* | | | Merge pull request #4094 from retronym/ticket/8962Jason Zaugg2014-11-061-0/+31
|\ \ \ \ | | | | | | | | | | SI-8962 Fix regression with skolems in pattern translation
| * | | | SI-8962 Fix regression with skolems in pattern translationJason Zaugg2014-11-061-0/+31
| | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During the refactoring of error reporting in 258d95c7b15, the result of `Context#reportError` was changed once we had switched to using a `ThrowingReporter`, which is still the case in post typer phase typechecking This was enough to provoke a type error in the enclosed test. Here's a diff of the typer log: % scalac-hash 258d95~1 -Ytyper-debug sandbox/test.scala 2>&1 | tee sandbox/good.log % scalac-hash 258d95 -Ytyper-debug sandbox/test.scala 2>&1 | tee sandbox/bad.log % diff -U100 sandbox/{good,bad}.log | gist --filename=SI-8962-typer-log.diff https://gist.github.com/retronym/3ccbe7e0791447d272a6 The test `Context#reportError` happens to be used when deciding whether the type checker should be lenient when it hits a type error. In lenient mode (see `adaptMismatchedSkolems`), it `adapt` retries with after slackening the expected type by replacing GADT and existential skolems with wildcard types. This is to accomodate known type-incorrect trees generated by the pattern matcher. This commit restores the old semantics of `reportError`, which means it is `false` when a `ThrowingReporter` is being used. For those still reading, here's some more details. The trees of the `run2` example from the enclosed test. Notice that after typechecking, `expr` has a type containing GADT skolems. The pattern matcher assumes that calling the case field accessor `expr` on the temporary val `x2 : Let[A with A]` containing the scrutinee will result in a compatible expression, however this it does not. Perhaps the pattern matcher should generate casts, rather than relying on the typer to turn a blind eye. ``` [[syntax trees at end of typer]] // t8962b.scala ... def run2[A](nc: Outer2[A,A]): Outer2[Inner2[A],A] = nc match { case (expr: Outer2[Inner2[?A2 with ?A1],?A2 with ?A1])Let2[A with A]((expr @ _{Outer2[Inner2[?A2 with ?A1],?A2 with ?A1]}){Outer2[Inner2[?A2 with ?A1],?A2 with ?A1]}){Let2[A with A]} => (expr{Outer2[Inner2[?A2 with ?A1],?A2 with ?A1]}: Outer2[Inner2[A],A]){Outer2[Inner2[A],A]} }{Outer2[Inner2[A],A]} [[syntax trees at end of patmat]] // t8962b.scala def run2[A](nc: Outer2[A,A]): Outer2[Inner2[A],A] = { case <synthetic> val x1: Outer2[A,A] = nc{Outer2[A,A]}; case5(){ if (x1.isInstanceOf[Let2[A with A]]) { <synthetic> val x2: Let2[A with A] = (x1.asInstanceOf[Let2[A with A]]: Let2[A with A]){Let2[A with A]}; { val expr: Outer2[Inner2[?A2 with ?A1],?A2 with ?A1] = x2.expr{<null>}; matchEnd4{<null>}((expr{Outer2[Inner2[?A2 with ?A1],?A2 with ?A1]}: Outer2[Inner2[A],A]){Outer2[Inner2[A],A]}){<null>} ... ```
* | | | Merge pull request #4093 from lrytz/t8960Lukas Rytz2014-11-065-5/+71
|\ \ \ \ | |/ / / |/| | | SI-8960 Bring back the SerialVersionUID to anonymous function classes
| * | | SI-8960 Bring back the SerialVersionUID to anonymous function classesLukas Rytz2014-11-055-5/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In PR #1673 / 4267444, the annotation `SerialVersionId` was changed from a `StaticAnnotation` to `ClassFileAnnotation` in order to enforce annotation arguments to be constants. That was 2.11.0. The ID value in the AnnotationInfo moved from `args` to `assocs`, but the backend was not adjusted. This was fixed in PR #3711 / ecbc9d0 for 2.11.1. Unfortunately, the synthetic AnnotationInfo that is added to anonymous function classes still used the old constructor (`args` instead of `assocs`), so extracting the value failed, and no field was added to the classfile.
* | | | Merge pull request #4092 from som-snytt/issue/5217Lukas Rytz2014-11-051-0/+17
|\ \ \ \ | | | | | | | | | | SI-5217 Companion privates in scope of class parms
| * | | | SI-5217 Companion privates in scope of class parmsSom Snytt2014-11-041-0/+17
| | |/ / | |/| | | | | | | | | | Test of the same. It progressed in 2.10.1.
* | | | Merge pull request #4069 from som-snytt/issue/8898Lukas Rytz2014-11-052-0/+27
|\ \ \ \ | | | | | | | | | | SI-8898 javap -fun under new style lambdas
| * | | | SI-8898 javap -fun under new style lambdasSom Snytt2014-11-042-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To support both -Ydelambdafy strategies, look for both inline (anonfun) and method (lambda) closure classes. For method (lambda) style, use the anonfun method that is invoked by the accessor. Also, the output of javap must be captured eagerly for filtering for the current target method. If the user asks for a module, e.g., `Foo$`, don't yield results for companion class, but for `Foo`, do yield companion module results. Just because.
* | | | | Merge pull request #4044 from retronym/ticket/5091Lukas Rytz2014-11-053-0/+39
|\ \ \ \ \ | | | | | | | | | | | | SI-5091 Move named-args cycle test from pending to neg
| * \ \ \ \ Merge pull request #7 from lrytz/t6051Jason Zaugg2014-11-041-0/+19
| |\ \ \ \ \ | | | | | | | | | | | | | | SI-6051 Test case, the issue seems to be fixed.
| | * | | | | SI-6051 Test case, the issue seems to be fixed.Lukas Rytz2014-11-041-0/+19
| | |/ / / /
| * / / / / SI-5091 Move named-args cycle test from pending to negJason Zaugg2014-10-102-0/+20
| |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a typechecking cycle, and since 4669ac180e5 we now report this in a clearer manner. Once we change the language to unconditionally interpret an assignent in argument position as a named argument would be the only way to get this over to `pos`.
* | | | | Merge pull request #4017 from lrytz/t6541Lukas Rytz2014-11-055-0/+113
|\ \ \ \ \ | |_|_|/ / |/| | | | SI-6541 valid wildcard existentials for case-module-unapply
| * | | | SI-6541 valid wildcard existentials for case-module-unapplyLukas Rytz2014-11-053-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of letting the compiler infer the return type of case module unapply methods, provide them explicitly. This is enabled only under -Xsource:2.12, because the change is not source compatible.
| * | | | Fix default value for ScalaVersionSettingLukas Rytz2014-11-042-0/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The default value was NoScalaVersion before, because tryToSet (where the default was supposed to be set) is not called at all if the option is not specified. The initial value of Xmigration is set to NoScalaVersion (which it was before, the AnyScalaVersion argument was ignored). AnyScalaVersion would be wrong, it would give a warning in `Map(1 -> "eis").values` if the option was not specified. See tests.
* | | | | Merge pull request #4036 from retronym/topic/opt-tail-callsJason Zaugg2014-11-043-0/+184
|\ \ \ \ \ | | | | | | | | | | | | SI-8893 Restore linear perf in TailCalls with nested matches
| * | | | | SI-8893 Test tailcall transform for mix of tail/non-tail recursionJason Zaugg2014-11-031-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Another excellent test suggestion by Dear Reviewer. After tail calls, the transform results in: ``` def tick(i: Int): Unit = { <synthetic> val _$this: Test.type = Test.this; _tick(_$this: Test.type, i: Int){ if (i.==(0)) () else if (i.==(42)) { Test.this.tick(0); _tick(Test.this, i.-(1).asInstanceOf[Int]()) } else _tick(Test.this, i.-(1).asInstanceOf[Int]()).asInstanceOf[Unit]() } }; ``` We test this by mostly exercising the tail-recursive code path with a level of recursion that would overflow the stack if we weren't using jumps.
| * | | | | SI-8893 Test case to show that tailrec continues to workJason Zaugg2014-11-021-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As suggested during code review, this test checks that the tailcalls phase recurses appropriately below a method that doesn and does not itself tail call. The test case is based on the pattern of code that to trigger super-linear performance in this transform.
| * | | | | SI-8893 Restore linear perf in TailCalls with nested matchesJason Zaugg2014-10-101-0/+129
| | |/ / / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Compilation perfomance of the enclosed test regressed when the new pattern matcher was introduced, specifically when the tail call elimination phase was made aware of its tree shapes in cd3d34203. The code added in that commit detects an application to a tail label in order to treat recursive calls in the argument as in tail position. If the transform of that argument makes no change, it falls back to `rewriteApply`, which transforms the argument again (although this time on a non-tail-position context.) This commit avoids the second transform by introducing a flag to `rewriteApply` to mark the arguments are pre-transformed. I don't yet see how that fixes the exponential performance, as on the surface it seems like a constant factor improvement. But the numbers don't lie, and we can now compile the test case in seconds, rather than before when it was running for > 10 minutes. This test case was based on a code pattern generated by the Avro serializer macro in: https://github.com/paytronix/utils-open/tree/release/2014/ernststavrosgrouper The exponential performance in that context is visualed here: https://twitter.com/dridus/status/519544110173007872 Thanks for @rmacleod2 for minimizing the problem.
* | | | | Merge pull request #4063 from som-snytt/issue/direct-showdef-testJason Zaugg2014-11-042-36/+24
|\ \ \ \ \ | | | | | | | | | | | | Make global-showdef a DirectTest
| * | | | | Reduce compiles for global-showdef testSom Snytt2014-10-282-7/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | You can only show one class or object at a time, but we can show one of each to reduce the compilations for this test. It seems the original issue happened because the test started to create class files after SI-8217. So, also stop compile after typer, because why stress the kitteh.
| * | | | | Make global-showdef a DirectTestSom Snytt2014-10-281-32/+18
| | |_|/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The test test/files/run/global-showdef.scala was outputting to the cwd instead of the test output dir. Good behavior is now inherited from DirectTest. Test frameworks, of any ilk or capability, rock.
* | | | | Merge pull request #4072 from soc/SI-4950Jason Zaugg2014-11-042-0/+21
|\ \ \ \ \ | |_|_|/ / |/| | | | SI-4950 Add tests, looks like it has been fixed earlier
| * | | | SI-4950 Add tests, looks like it has been fixed earlierSimon Ochsenreither2014-10-232-0/+21
| |/ / /
* | | | Merge pull request #4081 from retronym/ticket/8943Jason Zaugg2014-11-023-0/+40
|\ \ \ \ | | | | | | | | | | SI-8943 Handle non-public case fields in pres. compiler
| * | | | SI-8943 Handle non-public case fields in pres. compilerJason Zaugg2014-10-293-0/+40
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a case class is type checked, synthetic methods are added, such as the `hashCode`/`equals`, implementations of the `Product` interface. At the same time, a case accessor method is added for each non-public constructor parameter. This the accessor for a parameter named `x` is named `x$n`, where `n` is a fresh suffix. This is all done to retain universal pattern-matchability of case classes, irrespective of access. What is the point of allowing non-public parameters if pattern matching can subvert access? I believe it is to enables private setters: ``` case class C(private var x: String) scala> val x = new C("") x: C = C() scala> val c = new C("") c: C = C() scala> val C(x) = c x: String = "" scala> c.x <console>:11: error: variable x in class C cannot be accessed in C c.x ^ scala> c.x = "" <console>:13: error: variable x in class C cannot be accessed in C val $ires2 = c.x ^ <console>:10: error: variable x in class C cannot be accessed in C c.x = "" ^ ``` Perhaps I'm missing additional motivations. If you think scheme sounds like a binary compatiblity nightmare, you're right: https://issues.scala-lang.org/browse/SI-8944 `caseFieldAccessors` uses the naming convention to find the right accessor; this in turn is used in pattern match translation. The accessors are also needed in the synthetic `unapply` method in the companion object. Here, we must tread lightly to avoid triggering a typechecking cycles before; the synthesis of that method is not allowed to force the info of the case class. Instead, it uses a back channel, `renamedCaseAccessors` to see which parameters have corresonding accessors. This is pretty flaky: if the companion object is typechecked before the case class, it uses the private param accessor directly, which it happends to have access to, and which duly gets an expanded name to allow JVM level access. If the companion appears afterwards, it uses the case accessor method. In the presentation compiler, it is possible to typecheck a source file more than once, in which case we can redefine a case class. This uses the same `Symbol` with a new type completer. Synthetics must be re-added to its type. The reported bug occurs when, during the second typecheck, an entry in `renamedCaseAccessors` directs the unapply method to use `x$1` before it has been added to the type of the case class symbol. This commit clears corresponding entries from that map when we detect that we are redefining a class symbol. Case accessors are in need of a larger scale refactoring. But I'm leaving that for SI-8944.
* | | | Merge pull request #4079 from retronym/ticket/8941Jason Zaugg2014-11-025-0/+152
|\ \ \ \ | | | | | | | | | | SI-8941 Idempotent presentation compilation of implicit classes
| * | | | SI-8941 Deterministic tests for pres. compiler idempotencyJason Zaugg2014-10-282-0/+126
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A retrospective test case which covers typechecking idempotency which was introduced in 0b78a0196 / 148736c3df. It also tests the implicit class handling, which was fixed in the previous commit. It is difficult to test this using existing presentation compiler testing infrastructure, as one can't control at which point during the first typechecking the subesquent work item will be noticed. Instead, I've created a test with a custom subclass of `interactive.Global` that allows precise, deterministic control of when this happens. It overrides `signalDone`, which is called after each tree is typechecked, and watches for a defintion with a well known name. At that point, it triggers a targetted typecheck of the tree marked with a special comment. It is likely that this approach can be generalized to a reusable base class down the track. In particular, I expect that some of the nasty interactive ScalaDoc bugs could use this single-threaded approach to testing the presentation compiler.
| * | | | SI-8941 Idempotent presentation compilation of implicit classesJason Zaugg2014-10-283-0/+26
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we name an implicit class, `enterImplicitWrapper` is called, which enters the symbol for the factory method into the owning scope. The tree defining this factory method is stowed into `unit.synthetics`, from whence it will be retrieved and incorporated into the enclosing tree during typechecking (`addDerivedTrees`). The entry in `unit.synthetics` is removed at that point. However, in the presentation compiler, we can typecheck a unit more than once in a single run. For example, if, as happens in the enclosed test, a call to ask for a type at a given position interrupts type checking of the entire unit, we can get into a situation whereby the first type checking invocation has consumed the entry from `unit.synthetics`, and the second will crash when it can't find an entry. Similar problems have been solved in the past in `enterExistingSym` in the presentation compiler. This method is called when the namer encounters a tree that already has a symbol attached. See 0b78a0196 / 148736c3df. This commit takes a two pronged approach. First, `enterExistingSym` is extended to handle implicit classes. Any previous factory method in the owning scope is removed, and `enterImplicitWrapper` is called to place a new tree for the factory into `unit.synthetics` and to enter its symbol into the owning scope. Second, the assertions that could be tripped in `addDerivedTrees` and in `ImplicitClassWrapper#derivedSym` have been converted to positioned errors. The first change is sufficient to fix this bug, but the second is also enough to make the enclosed test pass, and has been retained as an extra layer of defence.
* | | | Merge pull request #4043 from retronym/ticket/3439-2Jason Zaugg2014-11-023-1/+37
|\ \ \ \ | | | | | | | | | | SI-3439 Fix use of implicit constructor params in super call
| * | | | SI-5454 Test case for another ticket fixed by the previous commitJason Zaugg2014-10-101-0/+10
| | | | |
| * | | | SI-3439 Fix use of implicit constructor params in super callJason Zaugg2014-10-102-1/+27
| | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When typechecking the primary constructor body, the symbols of constructor parameters of a class are owned by the class's owner. This is done make scoping work; you shouldn't be able to refer to class members in that position. However, other parts of the compiler weren't so happy about this arrangement. The enclosed test case shows that our checks for invalid, top-level implicits was spuriously triggered, and implicit search itself would fail. Furthermore, we had to hack `Run#compiles` to special case top-level early-initialized symbols. See SI-7264 / 86e6e9290. This commit: - introduces an intermediate local dummy term symbol which will act as the owner for constructor parameters and early initialized members - adds this to the `Run#symSource` map if it is top level - simplifies `Run#compiles` accordingly - tests this all in a top-level class, and one nested in another class.
* | | | Merge pull request #4076 from retronym/ticket/8934Jason Zaugg2014-11-027-0/+70
|\ \ \ \ | | | | | | | | | | SI-8934 Fix whitebox extractor macros in the pres. compiler
| * | | | SI-8934 Fix whitebox extractor macros in the pres. compilerJason Zaugg2014-10-277-0/+70
| | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The code that "aligns" patterns and extractors assumes that it can look at the type of the unapply method to figure the arity of the extractor. However, the result type of a whitebox macro does not tell the whole story, only after expanding an application of that macro do we know the result type. During regular compilation, this isn't a problem, as the macro application is expanded to a call to a synthetic unapply: { class anon$1 { def unapply(tree: Any): Option[(Tree, List[Treed])] } new anon$1 }.unapply(<unapply selector>) In the presentation compiler, however, we now use `-Ymacro-expand:discard`, which expands macros only to compute the type of the application (and to allow the macro to issue warnings/errors). The original application is retained in the typechecked tree, modified only by attributing the potentially-sharper type taken from the expanded macro. This was done to improve hyperlinking support in the IDE. This commit passes `sel.tpe` (which is the type computed by the macro expansion) to `unapplyMethodTypes`, rather than using the `finalResultType` of the unapply method. This is tested with a presentation compiler test (which closely mimics the reported bug), and with a pos test that also exercises `-Ymacro-expand:discard`. Prior to this patch, they used to fail with: too many patterns for trait api: expected 1, found 2
* | | | Merge pull request #4040 from retronym/ticket/8871Jason Zaugg2014-11-028-0/+28
|\ \ \ \ | |/ / / |/| | | FSC / REPL Bug Bonanza
| * | | SI-6613 Make Java enums work in FSC / REPLJason Zaugg2014-10-094-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We needed to hop from the enum's owner to its companion module in an early phase of the compiler. The enclosed test used to fail when this lookup returned NoSymbol on the second run of the resident compiler when triggered from `MixinTransformer`: the lookup didn't work after the flatten info transform. This is related to the fact that module classes are flattened into the enclosing package, but module accessors remain in the enclosing class.