summaryrefslogtreecommitdiff
path: root/test/files/pos
Commit message (Collapse)AuthorAgeFilesLines
* Actually retract clashing synthetic apply/unapply [backport]Adriaan Moors2017-04-122-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Also make this whole retraction of apply/unapply in case of a clashing user-defined member conditional on `-Xsource:2.12`. It turns out, as explained by lrytz, that the retraction mechanism was fragile because it relied on the order in which completers are run. We now cover both the case that: - the completer was run, the `IS_ERROR` flag was set, and the symbol was unlinked from its scope before `addSynthetics` in `typedStat` iterates over the scope (since the symbol is already unlinked, the tree is not added, irrespective of its flags). For this case, we also remove the symbol from the synthetics in its unit (for cleanliness). - the completer is triggered during the iteration in `addSynthetics`, which needs the check for the `IS_ERROR` flag during the iteration. Before, the completer just unlinked the symbol and set the IS_ERROR flag, and I assumed the typer dropped a synthetic tree with a symbol with that flag, because the tree was not shown in -Xprint output. In reality, the completer just always happened to run before the addSynthetics loop and unlinked the symbol from its scope in the test cases I came up with (including the 2.11 community build). Thankfully, the 2.12 community build caught my mistake, and lrytz provided a good analysis and review. Fix scala/bug#10261
* `CompleterWrapper` delegates `typeParams`.Adriaan Moors2017-04-041-0/+13
| | | | Fixes the problem reported with #5730 by xuwei-k in scala/scala-dev#352.
* Merge pull request #5736 from adriaanm/t10206Adriaan Moors2017-03-211-0/+15
|\ | | | | SI-10206 tighten fix for SI-6889
| * Test case for SI-10206Jason Zaugg2017-03-021-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implicit search implements a restriction that the target type for an implicit view should be more specific that AnyRef or AnyVal. scala> def foo(s: String): AnyVal = s <console>:12: error: the result type of an implicit conversion must be more specific than AnyVal def foo(s: String): AnyVal = s ^ Without this, an implicit value classes over `String` would be applied, which is unlikely to be what was intended. Implicit views are implemented as an implicit search for a function type with a structural type as its result. This structural type is created with: scala> val schema = analyzer.HasMethodMatching.apply(TermName("clone"), Nil, WildcardType) schema: $r.intp.global.analyzer.global.Type = ?{def clone(): ?} The quirk arises when, as above, we're seeking a member with the same name as a member of AnyRef. AnyRef is seen to be a subtype of the result type: scala> AnyRefClass.tpe <:< schema res23: Boolean = true Which leads to the implicit in the test case being disqualified. The typer opts to report the error about the inapplicability of the inherited clone method, so we don't even know why the implicit was discarded.
* | Improvements based on reviews by Lukas & JasonAdriaan Moors2017-03-021-0/+18
| |
* | Allow user-defined `[un]apply` in case companionAdriaan Moors2017-02-271-0/+36
|/ | | | | | | | | | | | | Don't emit a synthetic `apply` (or `unapply`) when it would clash with an existing one. This allows e.g., a `private apply`, along with a `case class` with a `private` constructor. We have to retract the synthetic method in a pretty roundabout way, as we need the other methods and the owner to be completed already. Unless we have to complete the synthetic `apply` while completing the user-defined one, this should not be a problem. If this does happen, this implies there's a cycle in computing the user-defined signature and the synthetic one, which is not allowed.
* SI-9331 Fix canEqual for case classes with HK type paramsJason Zaugg2017-01-091-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Time for the courage of our convictions: follow the advice of my TODO comment from SI-8244 / f62e280825 and fix `classExistentialType` once and for all. This is the change in the generated `canEquals` method in the test case; we no longer get a kind conformance error. ``` --- sandbox/old.log 2015-05-27 14:31:27.000000000 +1000 +++ sandbox/new.log 2015-05-27 14:31:29.000000000 +1000 @@ -15,7 +15,7 @@ case _ => throw new IndexOutOfBoundsException(x$1.toString()) }; override <synthetic> def productIterator: Iterator[Any] = runtime.this.ScalaRunTime.typedProductIterator[Any](Stuff.this); - <synthetic> def canEqual(x$1: Any): Boolean = x$1.$isInstanceOf[Stuff[Proxy[PP]]](); + <synthetic> def canEqual(x$1: Any): Boolean = x$1.$isInstanceOf[Stuff[_ <: [PP]Proxy[PP]]](); override <synthetic> def hashCode(): Int = ScalaRunTime.this._hashCode(Stuff.this); override <synthetic> def toString(): String = ScalaRunTime.this._toString(Stuff.this); override <synthetic> def equals(x$1: Any): Boolean = x$1 match { @@ -38,9 +38,3 @@ } } ``` I also heeded my own advice to pass in a prefix to this method.
* SI-9630 Fix spurious warning related to same-named case accessors [backport]Jason Zaugg2016-12-219-0/+101
| | | | | | | | | | | | | | | Hash consing of trees within pattern match analysis was broken, and considered `x1.foo#1` to be the same tree as `x1.foo#2`, even though the two `foo`-s referred to different symbols. The hash consing was based on `Tree#correspondsStructure`, but the predicate in that function cannot veto correspondance, it can only supplement the default structural comparison. I've instead created a custom tree comparison method for use in the pattern matcher that handles the tree shapes that we use. (cherry picked from commit 79a52e6807d2797dee12bab1730765441a0e222d)
* Merge pull request #5343 from milessabin/topic/si-2712-backportAdriaan Moors2016-10-1818-0/+206
|\ | | | | SI-2712 Add support for higher order unification
| * SI-2712 Add support for higher order unificationMiles Sabin2016-08-1518-0/+206
| |
* | Merge pull request #5345 from milessabin/topic/si-7046-backportAdriaan Moors2016-10-182-0/+23
|\ \ | | | | | | [nomerge] Partial fix for SI-7046
| * | Partial fix for SI-7046Miles Sabin2016-08-152-0/+23
| |/
* / SI-9760 Fix for higher-kinded GADT refinementMiles Sabin2016-08-151-0/+18
|/
* SI-9245 Fresher name in Try and testSom Snytt2016-06-071-0/+27
| | | | | | | | Fresh name for catcher gets a dollar. "Here, have a dollar." Test due to retronym demonstrates possible conflict. Over the lifetime of the universe, surely at least one code monkey would type in that identifier to catch a banana.
* Move t8449 to correct placeLukas Rytz2016-05-172-0/+13
| | | | Follow-up for https://github.com/scala/scala/pull/4117
* Update partest to 1.0.12, test case for reporting invalid flagsLukas Rytz2016-02-171-1/+1
| | | | | | Conflicts: test/files/pos/t3420.flags versions.properties
* Attacking exponential complexity in TypeMapsJason Zaugg2015-11-133-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | - Don't normalize existentials during the `contain`-s type map; `ExistentialType#normalize' calls contains internally and an exponential blowup ensues. - Ensure that the type map used in variance validation never returns modified types in order to avoid needless cloning of symbols. The enclosed test case still gets stuck in Uncurry, thanks to the way that `TypeMap#mapOver(List[Symbol])` recurses through the type first to check whether the type map would be an no-op or not. If not, it repeats the type map with cloned symbols. Doing the work twice at each level of recursion blows up the complexity. Removing that "fast path" allows the enclosed test to compile completely. As at this commit, it gets stuck in uncurry, which dealiases `s.List` to `s.c.i.List` within the type. Some more background on the troublesome part of `TypeMap`: http://lrytz.github.io/scala-aladdin-bugtracker/displayItem.do%3Fid=1210.html https://github.com/scala/scala/commit/f8b2b21050e7a2ca0f537ef70e3e0c8eead43abc
* 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> ```
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-29 09:07:59 +0000