summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* Clean implementation of sorts for scala.util.Sorting.Rex Kerr2015-06-161-477/+235
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Removed code based on Sun JDK sorts and implemented new (basic) sorts from scratch. Deferred to Java Arrays.sort whenever practical. Behavior of `scala.util.Sorting` should be unchanged, but changed documentation to specify when the Java methods are being used (as they're typically very fast). A JUnit test is provided. Performance is important for sorts. Everything is better with this patch, though it could be better yet, as described below. Below are sort times (in microseconds, SEM < 5%) for various 1024-element arrays of small case classes that compare on an int field (quickSort), or int arrays that use custom ordering (stableSort). Note: "degenerate" means there are only 16 values possible, so there are lots of ties. Times are all with fresh data (no re-using cache from run to run). Results: ``` random sorted reverse degenerate big:64k tiny:16 Old Sorting.quickSort 234 181 178 103 25,700 1.4 New Sorting.quickSort 170 27 115 74 18,600 0.8 Old Sorting.stableSort 321 234 236 282 32,600 2.1 New Sorting.stableSort 239 16 194 194 25,100 1.2 java.util.Arrays.sort 124 4 8 105 13,500 0.8 java.util.Arrays.sort|Box 126 15 13 112 13,200 0.9 ``` The new versions are uniformly faster, but uniformly slower than Java sorting. scala.util.Sorting has use cases that don't map easily in to Java unless everything is pre-boxed, but the overhead of pre-boxing is minimal compared to the sort. A snapshot of some of my benchmarking code is below. (Yes, lots of repeating myself--it's dangerous not to when trying to get somewhat accurate benchmarks.) ``` import java.util.Arrays import java.util.Comparator import math.Ordering import util.Sorting import reflect.ClassTag val th = ichi.bench.Thyme.warmed() case class N(i: Int, j: Int) {} val a = Array.fill(1024)( Array.tabulate(1024)(i => N(util.Random.nextInt, i)) ) var ai = 0 val b = Array.fill(1024)( Array.tabulate(1024)(i => N(i, i)) ) var bi = 0 val c = Array.fill(1024)( Array.tabulate(1024)(i => N(1024-i, i)) ) var ci = 0 val d = Array.fill(1024)( Array.tabulate(1024)(i => N(util.Random.nextInt(16), i)) ) var di = 0 val e = Array.fill(16)( Array.tabulate(65536)(i => N(util.Random.nextInt, i)) ) var ei = 0 val f = Array.fill(65535)( Array.tabulate(16)(i => N(util.Random.nextInt, i)) ) var fi = 0 val o = new Ordering[N]{ def compare(a: N, b: N) = if (a.i < b.i) -1 else if (a.i > b.i) 1 else 0 } for (s <- Seq("one", "two", "three")) { println(s) th.pbench{ val x = a(ai).clone; ai = (ai+1)%a.length; Sorting.quickSort(x)(o); x(x.length/3) } th.pbench{ val x = b(bi).clone; bi = (bi+1)%b.length; Sorting.quickSort(x)(o); x(x.length/3) } th.pbench{ val x = c(ci).clone; ci = (ci+1)%c.length; Sorting.quickSort(x)(o); x(x.length/3) } th.pbench{ val x = d(di).clone; di = (di+1)%d.length; Sorting.quickSort(x)(o); x(x.length/3) } th.pbench{ val x = e(ei).clone; ei = (ei+1)%e.length; Sorting.quickSort(x)(o); x(x.length/3) } th.pbench{ val x = f(fi).clone; fi = (fi+1)%f.length; Sorting.quickSort(x)(o); x(x.length/3) } } def ix(ns: Array[N]) = { val is = new Array[Int](ns.length) var i = 0 while (i < ns.length) { is(i) = ns(i).i i += 1 } is } val p = new Ordering[Int]{ def compare(a: Int, b: Int) = if (a > b) 1 else if (a < b) -1 else 0 } for (s <- Seq("one", "two", "three")) { println(s) val tag: ClassTag[Int] = implicitly[ClassTag[Int]] th.pbench{ val x = ix(a(ai)); ai = (ai+1)%a.length; Sorting.stableSort(x)(tag, p); x(x.length/3) } th.pbench{ val x = ix(b(bi)); bi = (bi+1)%b.length; Sorting.stableSort(x)(tag, p); x(x.length/3) } th.pbench{ val x = ix(c(ci)); ci = (ci+1)%c.length; Sorting.stableSort(x)(tag, p); x(x.length/3) } th.pbench{ val x = ix(d(di)); di = (di+1)%d.length; Sorting.stableSort(x)(tag, p); x(x.length/3) } th.pbench{ val x = ix(e(ei)); ei = (ei+1)%e.length; Sorting.stableSort(x)(tag, p); x(x.length/3) } th.pbench{ val x = ix(f(fi)); fi = (fi+1)%f.length; Sorting.stableSort(x)(tag, p); x(x.length/3) } } for (s <- Seq("one", "two", "three")) { println(s) th.pbench{ val x = a(ai).clone; ai = (ai+1)%a.length; Arrays.sort(x, o); x(x.length/3) } th.pbench{ val x = b(bi).clone; bi = (bi+1)%b.length; Arrays.sort(x, o); x(x.length/3) } th.pbench{ val x = c(ci).clone; ci = (ci+1)%c.length; Arrays.sort(x, o); x(x.length/3) } th.pbench{ val x = d(di).clone; di = (di+1)%d.length; Arrays.sort(x, o); x(x.length/3) } th.pbench{ val x = e(ei).clone; ei = (ei+1)%e.length; Arrays.sort(x, o); x(x.length/3) } th.pbench{ val x = f(fi).clone; fi = (fi+1)%f.length; Arrays.sort(x, o); x(x.length/3) } } def bx(is: Array[Int]): Array[java.lang.Integer] = { val Is = new Array[java.lang.Integer](is.length) var i = 0 while (i < is.length) { Is(i) = java.lang.Integer.valueOf(is(i)) i += 1 } Is } def xb(Is: Array[java.lang.Integer]): Array[Int] = { val is = new Array[Int](Is.length) var i = 0 while (i < is.length) { is(i) = Is(i).intValue i += 1 } is } val q = new Comparator[java.lang.Integer]{ def compare(a: java.lang.Integer, b: java.lang.Integer) = o.compare(a.intValue, b.intValue) } for (s <- Seq("one", "two", "three")) { println(s) val tag: ClassTag[Int] = implicitly[ClassTag[Int]] th.pbench{ val x = bx(ix(a(ai))); ai = (ai+1)%a.length; Arrays.sort(x, q); xb(x)(x.length/3) } th.pbench{ val x = bx(ix(b(bi))); bi = (bi+1)%b.length; Arrays.sort(x, q); xb(x)(x.length/3) } th.pbench{ val x = bx(ix(c(ci))); ci = (ci+1)%c.length; Arrays.sort(x, q); xb(x)(x.length/3) } th.pbench{ val x = bx(ix(d(di))); di = (di+1)%d.length; Arrays.sort(x, q); xb(x)(x.length/3) } th.pbench{ val x = bx(ix(e(ei))); ei = (ei+1)%e.length; Arrays.sort(x, q); xb(x)(x.length/3) } th.pbench{ val x = bx(ix(f(fi))); fi = (fi+1)%f.length; Arrays.sort(x, q); xb(x)(x.length/3) } } ```
* Merge pull request #4307 from som-snytt/issue/4339-2.10-bGrzegorz Kossakowski2015-02-234-41/+31
|\ | | | | SI-4339 Backpatch event errors and attr fix
| * [backport] SI-9060 Backpatch fifth-edition namesSom Snytt2015-02-152-38/+22
| | | | | | | | | | | | | | | | | | Because the compiler and library share some code in this version, compiler must exclude xml tags that look like Scala operators, such as `<:`. This is an upstream port of: scala-xml/commit/968f7bd94e934c781c19e25847ab09ac98cfbaf6
| * [backport] SI-4339 Event errors and attribute fixSom Snytt2015-02-132-3/+9
| | | | | | | | | | | | | | | | | | Improve attribute parsing and propagate errors across event thread. Otherwise tests just hang. This is tested, right? This is an upstream port of scala-xml 5f2cfadeb9e8574ed66f37dc7a7a868eb129a8a9
* | Scaladoc js location synch more robustAdriaan Moors2015-02-201-1/+1
| | | | | | | | | | | | Tested on: - Mac: FF35/Safari 8/Chrome 41 - Win: IE11
* | Merge pull request #4289 from retronym/ticket/8689Grzegorz Kossakowski2015-02-151-5/+2
|\ \ | | | | | | SI-8689 Avoid internal error in Promise after sequence of completions
| * | SI-8689 Avoid internal error in Promise after sequence of completionsViktor Klang2015-02-041-5/+2
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Calling `completeWith` when the `DefaultPromise` is already completed, leads to callbacks not being properly executed. This happened because `Future.InternalCallbackExecutor` extends `BatchingExecutor`[1] which assumes `unbatchedExecute` to be async, when in this case it is sync, and if there is an exception thrown by executing the batch, it creates a new batch with the remaining items from the current batch and submits that to `unbatchedExecute` and then rethrows, but if you have a sync `unbatchedExecute`, it will fail since it is not reentrant, as witnessed by the failed `require` as reported in this issue. This commit avoids problem by delegating `completeWith` to `tryComplete`, which has the effect of using `onComplete` + `tryComplete` i.s.o. `complete`, which means that when it fails (because of a benign race condition between completers) it won't throw an exception. It has been tested by the minimized reproducer. [1] Actually, in the 2.10.x branch where this patch is starting out, "The BatchingExecutor trait had to be inlined into InternalCallbackExecutor for binary compatibility.". This comment will be more literally correct in the context of 2.11.x and beyond
* / Backported fix for SI-7753 to 2.10.x.Miles Sabin2015-02-091-34/+55
|/
* SI-9027 Backport xml parser fixSom Snytt2014-12-041-6/+5
| | | | | | Fingers crossed, I have no local java 6 here to test. No test because no q"" on 2.10.
* Merge pull request #3998 from retronym/backport/7756Grzegorz Kossakowski2014-09-241-8/+27
|\ | | | | [backport] SI-7756 Uncripple refchecks in case bodies
| * [backport] SI-7756 Uncripple refchecks in case bodiesJason Zaugg2014-09-231-8/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In 65340ed4ad2e, parts of RefChecks were disabled when we traversed into the results of the new pattern matcher. Similar logic existed for the old pattern matcher, but in that case the Match / CaseDef nodes still existed in the tree. The new approach was too broad: important checks no longer scrutinized the body of cases. This commit turns the checks back on when it finds the remnants of a case body, which appears as an application to a label def. Conflicts: src/compiler/scala/tools/nsc/typechecker/RefChecks.scala Cherry pick of 3df1d77fc984b976efa68098206e801cf3b83a9e
* | Merge pull request #3859 from xeno-by/topic/fundep-materialization-210xGrzegorz Kossakowski2014-09-112-4/+30
|\ \ | | | | | | [backport] SI-7470 implements fundep materialization
| * | -Xfundep-materialization => -Yfundep-materializationEugene Burmako2014-09-092-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | To quote gkossakowski: Thinking about it more, could we hide this behind 'Y' flag instead? We have lesser obligation to keep around Y flags and this is something we should remove from 2.11/2.12.
| * | pull request feedbackEugene Burmako2014-07-031-0/+1
| | |
| * | [backport] SI-7470 implements fundep materializationEugene Burmako2014-07-022-4/+29
| | | | | | | | | | | | | | | Backports 21a8c6c from the 2.11.x branch under -Xfundep-materialization as per Miles Sabin's request. Thanks Miles!
* | | [backport] SI-8787 Backport Regex docSom Snytt2014-08-261-186/+291
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Backport the doc with two material changes: 1. need to use Groups to extract from Match, so say that in lieu of the 2.11 advice that the Regex instance can be used without recomputing the match; 2. and relatedly, in 2.10 there is no secondary constructor, so the doc for group names is moved back up to the class doc. Original doc update on PR #3923 was: 0e26910372d349c6ff7bbaa17fc8fe0bf568c5fe f98c53cb03f800b3d790f3866ab90f827fd131f5
* | | Merge pull request #3865 from xeno-by/topic/extractor-macros-210xGrzegorz Kossakowski2014-08-192-42/+64
|\ \ \ | | | | | | | | [backport] transformers no longer ignore UnApply.fun
| * | | [backport] transformers no longer ignore UnApply.funEugene Burmako2014-07-032-42/+64
| |/ / | | | | | | | | | Backports 7122560063 and 4133eb8454 from the 2.11.x branch
* | | Merge pull request #3860 from gourlaysama/wip/t7710-backportGrzegorz Kossakowski2014-08-192-2/+34
|\ \ \ | | | | | | | | [backport] SI-7710 fix memory performance of RegexParsers in jdk7u6+
| * | | [backport] SI-7710 fix memory performance of RegexParsers in jdk7u6+Antoine Gourlay2014-08-122-2/+34
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Backport of scala/scala-parser-combinators@91584dc. --- Starting with 1.7.0_06 [1], String.substring no longer reuses the internal char array of the String but make a copy instead. Since we call subSequence twice for *every* input character, this results in horrible parse performance and GC. With the benchmark from the (duplicate) ticket SI-8542, I get: BEFORE: parseAll(new StringReader(String)) For 100 items: 49 ms For 500 items: 97 ms For 1000 items: 155 ms For 5000 items: 113 ms For 10000 items: 188 ms For 50000 items: 1437 ms === parseAll(String) For 100 items: 4 ms For 500 items: 67 ms For 1000 items: 372 ms For 5000 items: 5693 ms For 10000 items: 23126 ms For 50000 items: 657665 ms AFTER: parseAll(new StringReader(String)) For 100 items: 43 ms For 500 items: 118 ms For 1000 items: 217 ms For 5000 items: 192 ms For 10000 items: 196 ms For 50000 items: 1424 ms === parseAll(String) For 100 items: 2 ms For 500 items: 8 ms For 1000 items: 16 ms For 5000 items: 79 ms For 10000 items: 161 ms For 50000 items: 636 ms [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6924259
* / / SI-8589 Performance improvement for ArrayCharSequence.toStringJeroen ter Voorde2014-06-191-1/+6
|/ /
* | SI-8596 Fix rangepos crasher with defaults, poly methodsJason Zaugg2014-05-291-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Regressed in SI-7915 / 3009a525b5 We should be deriving the position of the synthetic `Select` from `basefun1`, rather than `basefun`. In the new, enclosed test, the difference amounts to: new Container().typeParamAndDefaultArg[Any]() `------------ basefun1 --------------' `----------------- basefun ---------------' For monomorphic methods, these are one and the same, which is why `presentation/t7915` was working. I've extended that test to a polymorphic method to check that hyperlink resolution works.
* | Merge pull request #3678 from retronym/ticket/8479Jason Zaugg2014-04-073-4/+16
|\ \ | | | | | | SI-8479 Fix constructor default args under scaladoc
| * | SI-8479 Fix constructor default args under scaladocJason Zaugg2014-04-073-4/+16
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | The `DocDef` node hid the `DefDef` constructor from the scrutinee of the namer when determining if the class had constructor defaults or not. The current pattern for fixing these bugs is to delegate the check to `TreeInfo`, and account for the wrapper `DocDef` node. I've followed that pattern, but expressed my feelings about this approach in a TODO comment. Before this patch, the enclosed test failed with: error: not enough arguments for constructor SparkContext: (master: String, appName: String)SparkContext
* | Merge pull request #3655 from retronym/ticket/8442Grzegorz Kossakowski2014-03-262-4/+8
|\ \ | | | | | | SI-8442 Ignore stub annotation symbols in `AnnotationInfo#matches`
| * | SI-8442 Ignore stub annotation symbols in `AnnotationInfo#matches`Jason Zaugg2014-03-252-4/+8
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | And update the java `ClassFileParser` to create distinguished `StubClassSymbol`s, rather that a regular `ClassSymbol`s, when encountering a deficient classpath. This brings it into line with `Unpickler`, which has done as much since a55788e275f. This stops the enclosed test case from crashing when determining if the absent symbol, `A_1`, is a subclass of `@deprecated`. This is ostensibly fixes a regression, although it only worked in `2.10.[0-3]` by a fluke: the class file parser's promiscious exception handling caught and recovered from the NPE introduced in SI-7439! % javac -d /tmp test/files/run/t8442/{A,B}_1.java && qbin/scalac -classpath /tmp -d /tmp test/files/run/t8442/C_2.scala && (rm /tmp/A_1.class; true) && scalac-hash v2.10.0 -classpath /tmp -d /tmp test/files/run/t8442/C_2.scala warning: Class A_1 not found - continuing with a stub. warning: Caught: java.lang.NullPointerException while parsing annotations in /tmp/B_1.class two warnings found
* | Merge pull request #3551 from xeno-by/topic/typecheck-member-defJason Zaugg2014-03-253-62/+68
|\ \ | | | | | | [nomaster] backports 609047ba37
| * | [nomaster] typecheck(q"class C") no longer crashesEugene Burmako2014-03-233-62/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MemberDefs alone can't be typechecked as is, because namer only names contents of PackageDefs, Templates and Blocks. And, if not named, a tree can't be typed. This commit solves this problem by wrapping typecheckees in a trivial block and then unwrapping the result when it returns back from the typechecker. (cherry picked from commit 609047ba372ceaf06916d3361954bc949a6906ee)
* | | Merge pull request #3614 from retronym/ticket/8196Jason Zaugg2014-03-251-4/+7
|\ \ \ | | | | | | | | SI-8196 Runtime reflection robustness for STATIC impl details
| * | | SI-8196 Runtime reflection robustness for STATIC impl detailsJason Zaugg2014-03-111-4/+7
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Scala's runtime reflection works in few modes. The primary mode reads reads out the pickled signatures from ScalaSig annotations, if avaialable. However, these aren't available for Java-defined classes (obviously) nor for local Scala-defined classes (less obviously.), and the Scala `Symbol`s and `Types` must be reconstructed from the Java generic reflection metadata. This bug occurs in the last case, and is centered in `FromJavaClassCompleter`. In that completer, member fields and methods are given an owner based on the STATIC modifier. That makes sense for Java defined classes. I'm not 100% if it makes sense for Scala defined classes; maybe we should just skip them entirely? This patch still includes them, but makes the ownership-assignment more robust in the face of STATIC members emitted by the Scala compiler backend, such as the cache fields for structural calls. (It's reflection all the way down!). We might not have a companion module at all, so before we ended up owning those by `NoSymbol`, and before too long hit the dreaded NSDHNAO crash. That crash doesn't exist any more on 2.11 (it is demoted to a -Xdev warning), but this patch still makes sense on that branch. This commit makes `followStatic` and `enter` more robust when finding a suitable owner for static members. I've also factored out the duplicated logic between the two.
* | | [backport] no longer warns on calls to vampire macrosEugene Burmako2014-03-051-1/+1
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | As eloquently elaborated and cleverly named by Travis Brown, macros defined in structural types are useful: http://meta.plasm.us/posts/2013/07/12/vampire-methods-for-structural-types/. However, since such macros are on the intersection of a number of language features, as usual, there are bugs. This commit fixes an unwanted interaction of macros defined in structural types with the scala.language.reflectiveCalls guard. Since macro calls aren't going to be carried to runtime, there's no need to warn about them.
* | [backport] SI-7902 Fix spurious kind error due to an unitialized symbolJason Zaugg2014-02-091-1/+2
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tracked down this error: <none> is invariant, but type Y2 is declared covariant <none>'s bounds<notype> are stricter than type X2's declared bounds >: Nothing <: Any, <none>'s bounds<notype> are stricter than type Y2's declared bounds >: Nothing <: Any to `Symbol#typeParams` returning `List(NoSymbol)` if the symbol was not initialized. This happends in the enclosed test for: // checkKindBoundsHK() hkArgs = List(type M3) hkParams = List(type M2) This commit forces the symbol of the higher-kinded type argument before checking kind conformance. A little backstory: The `List(NoSymbol)` arises from: class PolyTypeCompleter... { // @M. If `owner` is an abstract type member, `typeParams` are all NoSymbol (see comment in `completerOf`), // otherwise, the non-skolemized (external) type parameter symbols override val typeParams = tparams map (_.symbol) The variation that triggers this problem gets into the kind conformance checks quite early on, during naming of: private[this] val x = ofType[InSeq] The inferred type of which is forced during: def addDerivedTrees(typer: Typer, stat: Tree): List[Tree] = stat match { case vd @ ValDef(mods, name, tpt, rhs) if !noFinishGetterSetter(vd) => // If we don't save the annotations, they seem to wander off. val annotations = stat.symbol.initialize.annotations (cherry picked from commit 03a06e02483eaf442158339c2edd6bcfd99847a3)
* [nomaster] corrects an error in reify’s documentationEugene Burmako2014-01-261-5/+5
|
* Merge pull request #3359 from huitseeker/issue/VarianceAdaptationsJason Zaugg2014-01-216-6/+6
|\ | | | | [backport] Backports library changes related to SI-6566 from a419799
| * Backports library changes related to SI-6566 from a419799François Garillot2014-01-136-6/+6
| | | | | | | | | | | | | | | | The idea of backporting this occured while developing the -source flag for SI-8126 : withouth this the library breaks at refchecks for a Scala compiler that checks type aliases variance. This shoudl be BC and promote good hygiene.
* | Merge pull request #3367 from retronym/backport/3363Jason Zaugg2014-01-201-25/+10
|\ \ | | | | | | [nomaster] Fix non-deterministic <:< for deeply nested types
| * | [nomaster] SI-8146 Fix non-deterministic <:< for deeply nested typesJason Zaugg2014-01-151-25/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Backported from master. This is a squashed commmit comprising: SI-8146 Pending test, diagnosis for bug in decidability of <:< (cherry picked from commit 8beeef339ad65f3308ece6fb0440cdb31b1ad404) SI-8146 Test cases for typechecking decidability Taken from "On Decidability of Nominal Subtyping with Variance" (Pierce, Kennedy), which was implemented in 152563b. Part of the implementation (SubTypePair) will be changed in the following commit to fix the non-deterministic errors typechecking heavily nested types involving aliases or annotations. (cherry picked from commit 2e28cf7f76c3d5fd0c2df4274f1af9acb42de699) SI-8146 Fix non-deterministic <:< for deeply nested types In the interests of keeping subtyping decidable [1], 152563b added some bookkeeping to `isSubType` to detect cycles. However, this was based on a hash set containing instances of `SubTypePair`, and that class had inconsistencies between its `hashCode` (in terms of `Type#hashCode`) and `equals` (in terms of `=:=`). This inconsistency can be seen in: scala> trait C { def apply: (Int @unchecked) } defined trait C scala> val intUnchecked = typeOf[C].decls.head.info.finalResultType intUnchecked: $r.intp.global.Type = Int @unchecked scala> val p1 = new SubTypePair(intUnchecked, intUnchecked) p1: $r.intp.global.SubTypePair = Int @unchecked <:<? Int @unchecked scala> val p2 = new SubTypePair(intUnchecked.withoutAnnotations, intUnchecked.withoutAnnotations) p2: $r.intp.global.SubTypePair = Int <:<? Int scala> p1 == p2 res0: Boolean = true scala> p1.hashCode == p2.hashCode res1: Boolean = false This commit switches to using `Type#==`, by way of the standard case class equality. The risk here is that you could find a subtyping computation that progresses in such a manner that we don't detect the cycle. It would need to produce an infinite stream of representations for types that were `=:=` but not `==`. If that happened, we'd fail to terminate, rather than judging the relationship as `false`. [1] http://research.microsoft.com/pubs/64041/fool2007.pdf (cherry picked from commit a09e143b7fd1c6b433386d45e9c5ae3548819b59) Conflicts: src/reflect/scala/reflect/internal/tpe/TypeComparers.scala src/reflect/scala/reflect/runtime/JavaUniverseForce.scala
* | | Merge pull request #3356 from retronym/ticket/8138Jason Zaugg2014-01-181-5/+7
|\ \ \ | | | | | | | | Fix bug with super-accessors / dependent types
| * | | SI-8143 Fix bug with super-accessors / dependent typesJason Zaugg2014-01-121-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Super-accessors are generated as `DefDef`'s with `EmptyTree` as a placeholder for the RHS. This is filled in later in `Mixin` in `completeSuperAccessor`. A change in `Uncurry` (SI-6443 / 493197f), however, converted this to a `{ EmptyTree }`, which evaded the pattern match in mixin. This commit adds a special case to the dependent method treatment in Uncurry to avoid generating redundant blocks.
* | | | Merge pull request #3364 from retronym/ticket/8152Jason Zaugg2014-01-151-3/+5
|\ \ \ \ | |_|/ / |/| | | [nomaster] Backport variance validator performance fix
| * | | [nomaster] SI-8152 Backport variance validator performance fixJason Zaugg2014-01-141-3/+5
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | % time qbin/scalac test/files/pos/t8146-performance.scala real 0m2.015s user 0m2.892s sys 0m0.215s % time scalac-hash v2.10.3 test/files/pos/t8146-performance.scala real 1m13.652s user 1m14.245s sys 0m0.508s Cherry-picks one hunk from 882f8e64.
* | | Merge pull request #3328 from retronym/ticket/8111v2.10.4-RC2Jason Zaugg2014-01-121-0/+23
|\ \ \ | |/ / |/| | Repair symbol owners after abandoned named-/default-args
| * | SI-8111 Expand the comment with a more detailed TODOJason Zaugg2014-01-081-3/+8
| | | | | | | | | | | | | | | As everone knows, undo/reset/retype/rollback are bandaids; we should try to treat the disease more directly.
| * | SI-8111 Repair symbol owners after abandoned named-/default-argsJason Zaugg2014-01-061-0/+18
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Names/Defaults eagerly transforms an application with temporaries to maintain evaluation order, and dutifully changes owners of symbols along the way. However, if this approach doesn't work out, we throw away this and try a auto-tupling. However, we an still witness symbols owned by the temporaries. This commit records which symbols are owned by the context.owner before `transformNamedApplication`, and rolls back the changes before `tryTupleApply`. Perhaps a better approach would be to separate the names/defaults applicability checks from the evaluation-order-preserving transform, and only call the latter after we have decided to go that way.
* | Merge pull request #3345 from retronym/ticket/8114Jason Zaugg2014-01-111-1/+26
|\ \ | | | | | | [nomaster] Binary compat. workaround for erasure bug
| * | [nomaster] SI-8114 Binary compat. workaround for erasure bug SI-7120Jason Zaugg2014-01-091-1/+26
| |/ | | | | | | | | | | | | | | | | | | | | We can't backport SI-7120 to 2.10.x as it changes erased signatures, which can lead to interop problems between 2.10.3 and 2.10.4. But, we can detect one of the nasty symptoms -- a bridge method with the same signature as its target -- and treat that. This commit detects duplicate bridges in the ASM (only) backend and removes them.
* / More clear implicitNotFound error for ExecutionContextJames Ward2014-01-081-1/+1
|/
* SI-8085 Fix BrowserTraverser for package objectsJason Zaugg2013-12-181-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A source file like: import foo.bar package object baz Is parsed into: package <empty> { import foo.bar package baz { object `package` } } A special case in Namers compensates by adjusting the owner of `baz` to be `<root>`, rather than `<empty>`. This wasn't being accounted for in `BrowserTraverser`, which underpins `-sourcepath`, and allows the presentation compiler to load top level symbols from sources outside those passes as the list of sources to compile. This bug did not appear in sources like: package p1 package object p2 { ... } ... because the parser does not wrap this in the `package <empty> {}` This goes some way to explaining why it has gone unnoticed for so long.
* Report error on code size overflow, log method name.Adriaan Moors2013-12-122-6/+10
| | | | | | | We used to silently skip class files that would exceed the JVM's size limits. While rare, this should still be an error. While I was at it, also included the name of the offending method.
* Merge pull request #3261 from adriaanm/ticket-6426Adriaan Moors2013-12-112-6/+6
|\ | | | | Revert ", importable _."
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-14 18:12:32 +0000