summaryrefslogtreecommitdiff
path: root/test/files/pos
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #4757 from lrytz/t9375-2.11Lukas Rytz2015-09-221-0/+18
|\ | | | | [backport] SI-9375 add synthetic readResolve only for static modules
| * [backport] SI-9375 add synthetic readResolve only for static modulesLukas Rytz2015-09-221-0/+18
| | | | | | | | | | | | | | | | | | For inner modules, the synthetic readResolve method would cause the module constructor to be invoked on de-serialization in certain situations. See the discussion in the ticket. Adds a comprehensive test around serializing and de-serializing modules.
* | fix t9370 so it works on Windows tooSeth Tisue2015-09-181-1/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | partest has custom code for -Xplugin handling (see DirectCompiler.updatePluginPath for details). that code has its own idea of what the syntax of -Xplugin is, different from Scalac's. partest's idea is that multiple paths should be separated by the platform classpath separator character, so : on Unix and ; on Windows. the .flags file here was using a colon, and that confuses partest on Windows, since partest was expecting a semicolon. it might be nice to fix partest to accept comma as the separator instead, which is standard for a scalac MultiStringSetting such as -Xplugin. but it turns out we have an out: we can just provide multiple -Xplugin flags. what evidence do I have that this is the right change? * the test still passes on both Windows and Mac OS X (manually tested); if Travis likes it, we'll know it passes on Linux too * I tried reverting Som's fix for SI-9370 (c32ba93) and the test failed, as expected, both with and without my change * I added a bunch of debugging output to DirectCompiler.updatePluginPath in partest, built a new partest jar, and used it to run the test on Windows with and without my fix, and verified by eye that the logic there was operating as expected in both cases and in conclusion, for Som's benefit: <insert cryptic joke here>
* SI-9475 Dependent PolyTypes are dependent typesVlad Ureche2015-09-171-0/+19
| | | | Such that uncurry can correctly un-dependify them.
* Merge pull request #4727 from SethTisue/unset-stray-execute-bitsSeth Tisue2015-09-1428-0/+0
|\ | | | | unset inappropriate execute bits
| * unset inappropriate execute bitsSeth Tisue2015-09-0228-0/+0
| | | | | | | | | | | | | | | | | | | | I imagine these date back to old Subversion days and are probably the result of inadvertent commits from Windows users with vcs client configs. having the bit set isn't really harmful most of the time, but it's just not right, and it makes the files stand out in directory listings for no reason
* | SI-9369 Fix pattern matcher warnings for diamond shaped inheritance.Gerard Basler2015-09-122-0/+25
| | | | | | | | | | | | | | | | | | | | A previous optimization (d44a86f432a7f9ca250b014acdeab02ac9f2c304) for pattern matcher exhaustivity checks used a smarter encoding to ensure that the scrutinee can be equal to one child only. However, in case of traits between the root and leave type, a child can be of several types and these types should not be in a mutually exclusive group. A simple solution (hat tip to retronym) is to just put traits and classes into separate groups.
* | Merge pull request #4704 from VladUreche/issue/9442Jason Zaugg2015-09-061-0/+14
|\ \ | |/ |/| SI-9442 Fix the uncurry-erasure types
| * SI-9442 Fix the uncurry-erasure typesVlad Ureche2015-08-231-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using the "uncurry-erased" type (the one after the uncurry phase) can lead to incorrect tree transformations. For example, compiling: ``` def foo(c: Ctx)(l: c.Tree): Unit = { val l2: c.Tree = l } ``` Results in the following AST: ``` def foo(c: Ctx, l: Ctx#Tree): Unit = { val l$1: Ctx#Tree = l.asInstanceOf[Ctx#Tree] val l2: c.Tree = l$1 // no, not really, it's not. } ``` Of course, this is incorrect, since `l$1` has type `Ctx#Tree`, which is not a subtype of `c.Tree`. So what we need to do is to use the pre-uncurry type when creating `l$1`, which is `c.Tree` and is correct. Now, there are two additional problems: 1. when varargs and byname params are involved, the uncurry transformation desugares these special cases to actual typerefs, eg: ``` T* ~> Seq[T] (Scala-defined varargs) T* ~> Array[T] (Java-defined varargs) =>T ~> Function0[T] (by name params) ``` we use the DesugaredParameterType object (defined in scala.reflect.internal.transform.UnCurry) to redo this desugaring manually here 2. the type needs to be normalized, since `gen.mkCast` checks this (no HK here, just aliases have to be expanded before handing the type to `gen.mkAttributedCast`, which calls `gen.mkCast`)
* | Fix typos in spec, docs and commentsMichał Pociecha2015-08-232-3/+3
|/
* SI-9393 fix modifiers of ClassBTypes for Java annotationsLukas Rytz2015-07-247-8/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Scala classfile and java source parsers make Java annotation classes (which are actually interfaces at the classfile level) look like Scala annotation classes: - the INTERFACE / ABSTRACT flags are not added - scala.annotation.Annotation is added as superclass - scala.annotation.ClassfileAnnotation is added as interface This makes type-checking @Annot uniform, whether it is defined in Java or Scala. This is a hack that leads to various bugs (SI-9393, SI-9400). Instead the type-checking should be special-cased for Java annotations. This commit fixes SI-9393 and a part of SI-9400, but it's still easy to generate invalid classfiles. Restores the assertions that were disabled in #4621. I'd like to leave these assertions in: they are valuable and helped uncovering the issue being fixed here. A new flag JAVA_ANNOTATION is introduced for Java annotation ClassSymbols, similar to the existing ENUM flag. When building ClassBTypes for Java annotations, the flags, superclass and interfaces are recovered to represent the situation in the classfile. Cleans up and documents the flags space in the area of "late" and "anti" flags. The test for SI-9393 is extended to test both the classfile and the java source parser.
* [backport] SI-9392 Avoid crash in GenBCode for incoherent treesJason Zaugg2015-07-232-0/+20
| | | | | | | | | | | | | | | | | | | | | | | A macro in shapeless was generating a tree of the form: ``` { class C#2 new C#2 }.setType(C#1) ``` This happened due to an error in the macro; it used untypecheck to try to fix the owner-chain consistency problem, but kept a reference to the previous version of the block-local class symbol `C` and used this in the resulting tree. This commit detects the particular situation we encountered, and avoids the crash by not creating the `NestedInfo` for the `BType` corresponding to `C#1`. The code comment discusses why I think this is safe, and suggests a refactoring that would mean we only ever try to construct `NestedInfo` when we are going to need them.
* [backport] SI-9393 Temporarily disable two assertions in GenBCodeJason Zaugg2015-07-233-0/+21
| | | | | | These cause a crash in the build of Play. We should try to bring these back once we have suitable annotation awareness. Perhaps they should only be `devWarning`-s, though.
* Merge pull request #4631 from janekdb/2.11.x-typos-t-vSeth Tisue2015-07-202-2/+2
|\ | | | | Fix 23 typos (t-v)
| * Fix 23 typos (t-v)Janek Bogucki2015-07-152-2/+2
| |
* | Merge pull request #4595 from som-snytt/issue/9370Lukas Rytz2015-07-164-0/+43
|\ \ | |/ |/| SI-9370 Xplugin scans plugin path for descriptor
| * SI-9370 Xplugin scans plugin path for descriptorSom Snytt2015-06-304-0/+43
| | | | | | | | | | Keep on scanning if the first entry doesn't yield a plugin.xml descriptor.
* | Fix 25 typos (s)Janek Bogucki2015-07-062-2/+2
| |
* | Fix 27 typos (p-r)Janek Bogucki2015-06-301-3/+3
|/
* Fix 25 typos (g-i)Janek Bogucki2015-06-221-1/+1
|
* Fix 36 typos (d-f)Janek Bogucki2015-06-213-3/+3
|
* Fix another several typosMichał Pociecha2015-06-181-1/+1
| | | | | | I just used text search to check whether there are no more typos like these corrected by janekdb, and by the way fixed also some other ones which I saw.
* Fix some typos (a-c)Janek Bogucki2015-06-181-1/+1
|
* SI-9356 more careful assertion in back-endAdriaan Moors2015-06-163-0/+21
| | | | | | | | | | | Calling `exists` on a `Symbol` triggers unpickling, which failed for reasons I did not investigate. Replaced `sym.exists` by `sym != NoSymbol`, which is good enough here. Also replaced assertion by a `devWarning`, since the logic seems too ad-hoc to actually crash the compiler when it's invalidated. Partially reverts b45a91fe22. See also #1532.
* SI-9321 Clarify spec for inheritance of qualified privateJason Zaugg2015-05-221-0/+10
| | | | | | | | | I checked the intent with Martin, who said: > [...] qualified private members are inherited like other members, > it’s just that their access is restricted. I've locked this in with a test as well.
* Merge pull request #4473 from retronym/ticket/9285Lukas Rytz2015-05-042-0/+2
|\ | | | | SI-9285 Don't warn about non-sensible equals in synthetic methods
| * SI-9285 Don't warn about non-sensible equals in synthetic methodsJason Zaugg2015-04-292-0/+2
| | | | | | | | | | | | | | Notably, in the synthetic equals method of a case class. Otherwise, we get an unsuppressable warning when defining a case class with a `Unit`-typed parameter, which some folks use a placeholder for real type while evolving a design.
* | Move test files to the right place.Gerard Basler2015-05-031-0/+33
|/
* Fix many typosMichał Pociecha2015-04-211-1/+1
| | | | | This commit corrects many typos found in scaladocs and comments. There's also fixed the name of a private method in ICodeCheckers.
* Merge pull request #4373 from retronym/topic/indylambda-permutations-2Lukas Rytz2015-04-102-0/+24
|\ | | | | SI-8359 Adjust parameter order of accessor method in Delambdafy
| * SI-8359 Adjust parameter order of accessor method in DelambdafyJason Zaugg2015-03-242-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Under `-Ydelambdafy:method`, a public, static accessor method is created to expose the private method containing the body of the lambda. Currently this accessor method has its parameters in the same order structure as those of the lambda body method. What is this order? There are three categories of parameters: 1. lambda parameters 2. captured parameters (added by lambdalift) 3. self parameters (added to lambda bodies that end up in trait impl classes by mixin, and added unconditionally to the static accessor method.) These are currently emitted in order #3, #1, #2. Here are examples of the current behaviour: BEFORE (trait): ``` % cat sandbox/test.scala && scalac-hash v2.11.5 -Ydelambdafy:method sandbox/test.scala && javap -private -classpath . 'Test$class' trait Member; class Capture; trait LambdaParam trait Test { def member: Member def foo { val local = new Capture (arg: LambdaParam) => "" + arg + member + local } } Compiled from "test.scala" public abstract class Test$class { public static void foo(Test); private static final java.lang.String $anonfun$1(Test, LambdaParam, Capture); public static void $init$(Test); public static final java.lang.String accessor$1(Test, LambdaParam, Capture); } ``` BEFORE (class): ``` % cat sandbox/test.scala && scalac-hash v2.11.5 -Ydelambdafy:method sandbox/test.scala && javap -private -classpath . Test trait Member; class Capture; trait LambdaParam abstract class Test { def member: Member def foo { val local = new Capture (arg: LambdaParam) => "" + arg + member + local } } Compiled from "test.scala" public abstract class Test { public abstract Member member(); public void foo(); private final java.lang.String $anonfun$1(LambdaParam, Capture); public Test(); public static final java.lang.String accessor$1(Test, LambdaParam, Capture); } ``` Contrasting the class case with Java: ``` % cat sandbox/Test.java && javac -d . sandbox/Test.java && javap -private -classpath . Test public abstract class Test { public static class Member {}; public static class Capture {}; public static class LambaParam {}; public static interface I { public abstract Object c(LambaParam arg); } public abstract Member member(); public void test() { Capture local = new Capture(); I i1 = (LambaParam arg) -> "" + member() + local; } } Compiled from "Test.java" public abstract class Test { public Test(); public abstract Test$Member member(); public void test(); private java.lang.Object lambda$test$0(Test$Capture, Test$LambaParam); } ``` We can see that in Java 8 lambda parameters come after captures. If we want to use Java's LambdaMetafactory to spin up our anoymous FunctionN subclasses on the fly, our ordering must change. I can see three options for change: 1. Adjust `LambdaLift` to always prepend captured parameters, rather than appending them. I think we could leave `Mixin` as it is, it already prepends the self parameter. This would result a parameter ordering, in terms of the list above: #3, #2, #1. 2. More conservatively, do this just for methods known to hold lambda bodies. This might avoid needlessly breaking code that has come to depend on our binary encoding. 3. Adjust the parameters of the accessor method only. The body of this method can permute params before calling the lambda body method. This commit implements option #2. In also prototyped #1, and found it worked so long as I limited it to non-constructors, to sidestep the need to make corresponding changes elsewhere in the compiler to avoid the crasher shown in the enclosed test case, which was minimized from a bootstrap failure from an earlier a version of this patch. We would need to defer option #1 to 2.12 in any case, as some of these lifted methods are publicied by the optimizer, and we must leave the signatures alone to comply with MiMa. I've included a test that shows this in all in action. However, that is currently disabled, as we don't have a partest category for tests that require Java 8.
* | Merge pull request #4306 from som-snytt/issue/3368-bAdriaan Moors2015-04-092-0/+6
|\ \ | | | | | | SI-3368 CDATA gets a Node
| * | SI-3368 CDATA gets a NodeSom Snytt2015-04-082-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | XML Parser uses `scala.xml.PCData`. A compiler flag `-Yxml:coalescing`, analogous to `DocumentBuilderFactory.setCoalescing`, turns `PCData` nodes into `Text` nodes and coalesces sibling text nodes. This change also fixes parse errors such as rejecting a sequence of CDATA sections. A sequence of "top level" nodes are not coalesced. ``` scala> <a><b/>start<![CDATA[hi & bye]]><c/>world<d/>stuff<![CDATA[red & black]]></a> res0: scala.xml.Elem = <a><b/>start<![CDATA[hi & bye]]><c/>world<d/>stuff<![CDATA[red & black]]></a> scala> :replay -Yxml:coalescing Replaying: <a><b/>start<![CDATA[hi & bye]]><c/>world<d/>stuff<![CDATA[red & black]]></a> res0: scala.xml.Elem = <a><b/>starthi &amp; bye<c/>world<d/>stuffred &amp; black</a> ```
* | | Merge pull request #4403 from gourlaysama/wip/t9239-generic-signatureAdriaan Moors2015-04-092-0/+18
|\ \ \ | |/ / |/| | SI-9239 fix java generic signature when traits extend classes
| * | SI-9239 fix java generic signature when traits extend classesAntoine Gourlay2015-03-252-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Given the following code: class C1[T] trait T1[T] extends C1[T] class C2[T] extends T1[T] The generic signature of C2 changed after ced3ca8 from "C1[T], T1[T]" to "Object, T1[T]", even though C1 was still marked as a superclass in the bytecode... C1 was removed because a subclass (T1) appeared later on, and it was possible for a trait to cause a class to be evicted. It turns out that if a class A appears in "parents", it *always* has to stay in the signature: if a trait later in the list inherits from some class, that class has to be a superclass of A (per SLS §5.1), or A itself, so in any case, the most specific superclass is A, so A should stay in the signature. Thus minimizeParents now only allows traits/interfaces to be removed from the list (the refactoring in 7552739, moving from mixinClasses to parents, makes this much easier to fix). This didn't happen for non-generic signatures because there are two separate fields in the classfile for this (one for the superclass, one for interfaces), so interfaces were processed on their own. Thus non-parametrized classes were not affected. Anything that used erased types at runtime was also fine (like isInstanceOf checks), and anything that used ScalaSignature was also unaffected. Maybethat's why so few things broke... See the test for how this affects Java (hint: badly). This changes very few things when building scala itself, and the changes seem sensible: --- sandbox/lib/scala-library.jar#!scala/runtime/NonLocalReturnControl.class +++ build/pack/lib/scala-library.jar#!scala/runtime/NonLocalReturnControl.class - Generic Signature: <T:Ljava/lang/Object;>Ljava/lang/Object;Lscala/util/control/ControlThrowable; + Generic Signature: <T:Ljava/lang/Object;>Ljava/lang/Throwable;Lscala/util/control/ControlThrowable; --- sandbox/lib/scala-library.jar#!scala/collection/mutable/QueueProxy$$anon$1.class +++ build/pack/lib/scala-library.jar#!scala/collection/mutable/QueueProxy$$anon$1.class - Generic Signature: Ljava/lang/Object;Lscala/collection/mutable/QueueProxy<TA;>; + Generic Signature: Lscala/collection/mutable/Queue<TA;>;Lscala/collection/mutable/QueueProxy<TA;>; --- sandbox/lib/scala-library.jar#!scala/collection/mutable/Iterable$.class +++ build/pack/lib/scala-library.jar#!scala/collection/mutable/Iterable$.class - Generic Signature: Ljava/lang/Object;Lscala/collection/generic/TraversableFactory<Lscala/collection/mutable/Iterable;>; + Generic Signature: Lscala/collection/generic/GenTraversableFactory<Lscala/collection/mutable/Iterable;>;Lscala/collection/generic/TraversableFactory<Lscala/collection/mutable/Iterable;>; --- sandbox/lib/scala-library.jar#!scala/collection/immutable/Traversable$.class +++ build/pack/lib/scala-library.jar#!scala/collection/immutable/Traversable$.class - Generic Signature: Ljava/lang/Object;Lscala/collection/generic/TraversableFactory<Lscala/collection/immutable/Traversable;>; + Generic Signature: Lscala/collection/generic/GenTraversableFactory<Lscala/collection/immutable/Traversable;>;Lscala/collection/generic/TraversableFactory<Lscala/collection/immutable/Traversable;>; --- sandbox/lib/scala-library.jar#!scala/collection/immutable/Iterable$.class +++ build/pack/lib/scala-library.jar#!scala/collection/immutable/Iterable$.class - Generic Signature: Ljava/lang/Object;Lscala/collection/generic/TraversableFactory<Lscala/collection/immutable/Iterable;>; + Generic Signature: Lscala/collection/generic/GenTraversableFactory<Lscala/collection/immutable/Iterable;>;Lscala/collection/generic/TraversableFactory<Lscala/collection/immutable/Iterable;>; --- sandbox/lib/scala-library.jar#!scala/collection/mutable/Traversable$.class +++ build/pack/lib/scala-library.jar#!scala/collection/mutable/Traversable$.class - Generic Signature: Ljava/lang/Object;Lscala/collection/generic/TraversableFactory<Lscala/collection/mutable/Traversable;>; + Generic Signature: Lscala/collection/generic/GenTraversableFactory<Lscala/collection/mutable/Traversable;>;Lscala/collection/generic/TraversableFactory<Lscala/collection/mutable/Traversable;>; --- sandbox/lib/scala-library.jar#!scala/throws.class +++ build/pack/lib/scala-library.jar#!scala/throws.class - Generic Signature: <T:Ljava/lang/Throwable;>Ljava/lang/Object;Lscala/annotation/StaticAnnotation; + Generic Signature: <T:Ljava/lang/Throwable;>Lscala/annotation/Annotation;Lscala/annotation/StaticAnnotation; --- sandbox/lib/scala-library.jar#!scala/collection/mutable/StackProxy$$anon$1.class +++ build/pack/lib/scala-library.jar#!scala/collection/mutable/StackProxy$$anon$1.class - Generic Signature: Ljava/lang/Object;Lscala/collection/mutable/StackProxy<TA;>; + Generic Signature: Lscala/collection/mutable/Stack<TA;>;Lscala/collection/mutable/StackProxy<TA;>; --- sandbox/lib/scala-library.jar#!scala/collection/convert/Wrappers$IterableWrapper.class +++ build/pack/lib/scala-library.jar#!scala/collection/convert/Wrappers$IterableWrapper.class - Generic Signature: <A:Ljava/lang/Object;>Ljava/lang/Object;Lscala/collection/convert/Wrappers$IterableWrapperTrait<TA;>;Lscala/Product;Lscala/Serializable; + Generic Signature: <A:Ljava/lang/Object;>Ljava/util/AbstractCollection<TA;>;Lscala/collection/convert/Wrappers$IterableWrapperTrait<TA;>;Lscala/Product;Lscala/Serializable; --- sandbox/lib/scala-library.jar#!scala/collection/Iterable$.class +++ build/pack/lib/scala-library.jar#!scala/collection/Iterable$.class - Generic Signature: Ljava/lang/Object;Lscala/collection/generic/TraversableFactory<Lscala/collection/Iterable;>; + Generic Signature: Lscala/collection/generic/GenTraversableFactory<Lscala/collection/Iterable;>;Lscala/collection/generic/TraversableFactory<Lscala/collection/Iterable;>; --- sandbox/lib/scala-library.jar#!scala/collection/Traversable$.class +++ build/pack/lib/scala-library.jar#!scala/collection/Traversable$.class - Generic Signature: Ljava/lang/Object;Lscala/collection/generic/TraversableFactory<Lscala/collection/Traversable;>; + Generic Signature: Lscala/collection/generic/GenTraversableFactory<Lscala/collection/Traversable;>;Lscala/collection/generic/TraversableFactory<Lscala/collection/Traversable;>; --- sandbox/lib/scala-library.jar#!scala/collection/parallel/AdaptiveWorkStealingForkJoinTasks$WrappedTask.class +++ build/pack/lib/scala-library.jar#!scala/collection/parallel/AdaptiveWorkStealingForkJoinTasks$WrappedTask.class - Generic Signature: <R:Ljava/lang/Object;Tp:Ljava/lang/Object;>Ljava/lang/Object;Lscala/collection/parallel/ForkJoinTasks$WrappedTask<TR;TTp;>;Lscala/collection/parallel/AdaptiveWorkStealingTasks$WrappedTask<TR;TTp;>; + Generic Signature: <R:Ljava/lang/Object;Tp:Ljava/lang/Object;>Lscala/concurrent/forkjoin/RecursiveAction;Lscala/collection/parallel/ForkJoinTasks$WrappedTask<TR;TTp;>;Lscala/collection/parallel/AdaptiveWorkStealingTasks$WrappedTask<TR;TTp;>;
* | | Merge pull request #4370 from gbasler/ticket/SI-9181Adriaan Moors2015-04-063-1/+808
|\ \ \ | | | | | | | | SI-9181 Exhaustivity checking does not scale (regression)
| * | | Add a check to ensure that if the formulas originating from the exhaustivity /Gerard Basler2015-03-023-1/+808
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | reachability analysis are too big to be solved in reasonable time, then we skip the analysis. I also cleaned up warnings. Why did `t9181.scala` work fine with 2.11.4, but is now running out of memory? In order to ensure that the scrutinee is associated only with one of the 400 derived classes we add 400*400 / 2 ~ 80k clauses to ensure mutual exclusivity. In 2.11.4 the translation into CNF used to fail, since it would blow up already at this point in memory. This has been fixed in 2.11.5, but now the DPLL solver is the bottleneck. There's a check in the search for all models (exhaustivity) that it would avoid a blow up, but in the search for a model (reachability), such a check is missing.
* | | | Merge pull request #4375 from som-snytt/issue/8861Lukas Rytz2015-03-312-0/+12
|\ \ \ \ | |_|/ / |/| | | SI-8861 Handle alias when probing for Any
| * | | SI-8861 Handle alias when probing for AnySom Snytt2015-03-092-0/+12
| |/ / | | | | | | | | | | | | | | | If args to a method are alias types, dealias to see if they contain Any before warning about inferring it. Similarly for return and expected types.
* | | Merge pull request #4380 from retronym/ticket/9020Jason Zaugg2015-03-242-0/+11
|\ \ \ | | | | | | | | SI-9020 Avoid spurious value discarding warning post-typer
| * | | SI-9020 Avoid spurious value discarding warning post-typerJason Zaugg2015-03-122-0/+11
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Typechecking during the specialization phase was emitting a bogus warning about value discarding. Such warnings in the typer should be guarded by `!isPastTyper` to restrict the analysis to the code the user originally wrote, rather than the results of later typechecking. I've made this change to the value discarding warning. I've also changed a numeric widening warning in the vicinity, although I do not have a test case for that.
* | | Merge pull request #4389 from retronym/topic/jesperJason Zaugg2015-03-241-0/+30
|\ \ \ | | | | | | | | Resurrect a test for type inference
| * | | Resurrect a test for type inferenceJason Zaugg2015-03-171-0/+30
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This test was removed in ... when case class extension was disallowed. But the intent of the test was actually to exercise a path through type inference, described in `Infer#exprTypeArgs`. When I remove that special case, the test still fails: ``` test/files/pos/jesper.scala:29: error: No implicit view available from Pair.Cons[Int,Pair.Cons[Boolean,Pair.End]] => Boolean. val x2 : Boolean = p.find[Boolean] // Doesn't compile ^ one error found ``` This special case is important to understand when deciphering the inference in this program: ``` object Test { trait Cov[+A] def cov[A](implicit ev: Cov[A]): A = ??? implicit def covImp[A]: Cov[A] = ??? trait Inv[A] def inv[A](implicit ev: Inv[A]): A = ??? implicit def invImp[A]: Inv[A] = ??? trait Con[-A] def con[A](implicit ev: Con[A]): A = ??? implicit def conImp[A]: Con[A] = ??? cov : String // (Test.this.cov[String](Test.this.covImp[Nothing]): String); // (Test.this.cov[Nothing](Test.this.covImp[Nothing]): String) (or, without the special case in exprTypeArgs) inv : String // (Test.this.inv[Nothing](Test.this.invImp[Nothing]): String); con : String // (Test.this.con[Any](Test.this.conImp[Any]): String) } ```
* / / Workaround for SI-9111Lukas Rytz2015-03-113-0/+24
|/ / | | | | | | | | | | | | | | | | The inliner forces some method symbols to complete that would not be completed otherwise. This triggers SI-9111, in which the completer of a valid Java method definition reports an error in mixed compilation. The workaround disables error reporting while completing lazy method and class symbols in the backend.
* | Merge pull request #4347 from retronym/ticket/8801Adriaan Moors2015-02-191-0/+21
|\ \ | | | | | | SI-8801 Another test for fixed exponential-time compilation
| * | SI-8801 Another test for fixed exponential-time compilationJason Zaugg2015-02-201-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Turns out that SI-9157 was a duplicate of SI-8801. This commit adds Paul's test, whose compile time is now back in the troposphere. % time qscalac test/files/pos/t8801.scala real 0m1.294s user 0m3.978s sys 0m0.240s
* | | Merge pull request #4309 from som-snytt/issue/9116-bAdriaan Moors2015-02-181-0/+7
|\ \ \ | |/ / |/| | SI-9116 Set.subsets has a param list
| * | SI-9116 Set.subsets has a param listSom Snytt2015-02-091-0/+7
| |/ | | | | | | | | | | | | | | | | Now both of the overloaded variants have a parameter list. This seems to make type inference happier. Or it makes someone happier. The user is unaware whether `subsets()` takes a default arg. But happily, empty application still kicks in.
* / SI-9157 Avoid exponential blowup with chained type projectionsJason Zaugg2015-02-181-0/+13
|/ | | | | | | | | | | | | | | | | Calling `findMember` in the enclosed test was calling into `NonClassTypeRef#relativeInfo` an exponentially-increasing number of times, with respect to the length of the chained type projections. The numbers of calls increased as: 26, 326, 3336, 33446, 334556. Can any pattern spotters in the crowd that can identify the sequence? (I can't.) Tracing the calls saw we were computing the same `memberType` repeatedly. This part of the method was not guarded by the cache. I have changed the method to use the standard idiom of using the current period for cache invalidation. The enclosed test now compiles promptly, rather than in geological time.
* Merge pull request #4274 from retronym/ticket/9123Adriaan Moors2015-02-092-0/+11
|\ | | | | SI-9123 More coherent trees with patmat, dependent types
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-15 16:47:37 +0000