summaryrefslogtreecommitdiff
path: root/test/junit
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #4716 from Ichoran/issue/9388Lukas Rytz2015-09-211-0/+24
|\ | | | | SI-9388 Fix Range behavior around Int.MaxValue
| * SI-9388 Fix Range behavior around Int.MaxValueRex Kerr2015-09-191-0/+24
| | | | | | | | | | | | | | | | | | | | terminalElement (the element _after_ the last one!) was used to terminate foreach loops and sums of non-standard instances of Numeric. Unfortunately, this could result in the end wrapping around and hitting the beginning again, making the first element bad. This patch fixes the behavior by altering the loop to end after the last element is encountered. The particular flavor was chosen out of a few possibilities because it gave the best microbenchmarks on both large and small ranges. Test written. While testing, a bug was also uncovered in NumericRange, and was also fixed. In brief, the logic around sum is rather complex since division is not unique when you have overflow. Floating point has its own complexities, too. Also updated incorrect test t4658 that insisted on incorrect answers (?!) and added logic to make sure it at least stays self-consistent, and fixed the range.scala test which used the same wrong (overflow-prone) formula that the Range collection did.
* | Fix NPE in PagedSeq.slice at end of seqTomas Janousek2015-09-211-0/+6
|/ | | | | | | | | | | | | | See https://github.com/scala/scala-parser-combinators/issues/70 Basically the same thing as SI-6615, including the fact everything works okay if the PagedSeq is printed before calling slice. It might seem strange that this allows taking slices that start beyond the end, but - this was possible anyway if one forced the entire sequence, and - it is reasonable to be able to take a slice at the very end (not beyond it) and get an empty sequence, which is exactly what StreamReader in scala-parser-combinators does and gets an NPE.
* SI-8346 Re-established soundness of toSet (element type widening)Rex Kerr2015-08-261-0/+81
| | | | | | | | | | | | | | | toSet needs to rebuild some child classes, but not others, as toSet is allowed to widen element types (which the invariant Set normally cannot do), and some sets rely upon their invariance. Thus, sets that rely upon their invariance now rebuild themselves into a generic set upon toSet, while those that do not just sit there. Note: there was a similar patch previously that fixed the same problem, but this is a reimplementation to circumvent license issues. Note: the newBuilder method was benchmarked as (surprisingly!) the most efficient way to create small sets, so it is used where sets may need to be rebuild.
* Fix typos in spec, docs and commentsMichał Pociecha2015-08-231-1/+1
|
* SI-9393 fix modifiers of ClassBTypes for Java annotationsLukas Rytz2015-07-241-0/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Prevent infinite recursion in ProdConsAnalyzerLukas Rytz2015-07-231-0/+42
| | | | | | When an instruction is its own producer or consumer, the `initialProducer` / `ultimateConsumer` methods would loop. While loops or @tailrec annotated methods can generate such bytecode.
* Improve some names (t-v)Janek Bogucki2015-07-151-1/+1
|
* Fix 23 typos (m-o)Janek Bogucki2015-06-282-2/+2
|
* Merge pull request #4552 from lrytz/opt/closureInliningJason Zaugg2015-06-243-12/+262
|\ | | | | Closure elimination for new backend
| * Producers / Consumers AnalysisLukas Rytz2015-06-223-12/+262
| | | | | | | | | | | | | | | | | | | | | | | | | | | | ASM has a built-in `SourceValue` analysis which computes for each value a set of instructions that may possibly have constructed it. The ProdConsAnalyzer class provides additional queries over the result of the SourceValue analysis: - consumers of values - tracking producers / consumers through copying operations (load, store, etc) A fix to (and therefore a new version of) ASM was required. See here: https://github.com/scala/scala-asm/commit/94106a5472
* | Fix 25 typos (g-i)Janek Bogucki2015-06-222-2/+2
|/
* Merge pull request #4529 from lrytz/inlineAccessibilityJason Zaugg2015-06-191-6/+10
|\ | | | | Fix illegal inlining of instructions accessing protected members
| * Fix illegal inlining of instructions accessing protected membersLukas Rytz2015-05-281-6/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There were two issues in the new inliner that would cause a VerifyError and an IllegalAccessError. First, an access to a public member of package protected class C can only be inlined if the destination class can access C. This is tested by t7582b. Second, an access to a protected member requires the receiver object to be a subtype of the class where the instruction is located. So when inlining such an access, we need to know the type of the receiver object - which we don't have. Therefore we don't inline in this case for now. This can be fixed once we have a type propagation analyis. https://github.com/scala-opt/scala/issues/13. This case is tested by t2106. Force kmpSliceSearch test to delambdafy:inline See discussion on https://github.com/scala/scala/pull/4505. The issue will go away when moving to indy-lambda.
* | Merge pull request #4527 from nicky-zs/fix_BigDecimalLukas Rytz2015-06-181-0/+32
|\ \ | | | | | | fix BigDecimal losing MathContext
| * | make BigDecimalTest.testMathContext a bit easier to understandZhong Sheng2015-06-181-13/+14
| | |
| * | add more test for testMathContextZhong Sheng2015-05-291-2/+26
| | |
| * | add unit test for MathContext lostZhong Sheng2015-05-281-0/+7
| |/
* | SI-9348 Fix missing last element in exclusive floating point rangesNiko Vuokko2015-06-172-1/+38
| | | | | | | | | | Fix exclusive floating point ranges to contain also the last element when the end-start difference is not an integer multiple of step.
* | Merge pull request #4534 from Ichoran/sorting-reimplAdriaan Moors2015-06-161-0/+69
|\ \ | | | | | | Clean implementation of sorts for scala.util.Sorting.
| * | Clean implementation of sorts for scala.util.Sorting.Rex Kerr2015-06-011-0/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 #4519 from lrytz/opt/nullness-2.11Jason Zaugg2015-06-072-0/+247
|\ \ \ | |/ / |/| | Nullness Analysis for GenBCode
| * | Fix aliasing / nullness of CHECKCASTLukas Rytz2015-06-041-0/+26
| | |
| * | Address review feedbackLukas Rytz2015-05-251-9/+9
| | | | | | | | | | | | | | | | | | Address feedback in #4516 / 57b8da4cd8. Save allocations of NullnessValue - there's only 4 possible instances. Also save tuple allocations in InstructionStackEffect.
| * | Enable nullness analysis in the inlinerLukas Rytz2015-05-251-0/+16
| | | | | | | | | | | | | | | | | | | | | When inlining an instance call, the inliner has to ensure that a NPE is still thrown if the receiver object is null. By using the nullness analysis, we can avoid emitting this code in case the receiver object is known to be not-null.
| * | Nullness AnalysisLukas Rytz2015-05-221-0/+205
| |/ | | | | | | | | | | | | | | Tracks nullness of values using an ASM analyzer. Tracking nullness requires alias tracking for local variables and stack values. For example, after an instance call, local variables that point to the same object as the receiver are treated not-null.
* / SI-9332 Iterator.span exhausts leading iteratorSom Snytt2015-05-271-0/+10
|/ | | | | | | | | | | | | Since the leading and trailing iterators returned by span share the underlying iterator, the leading iterator must flag when it is exhausted (when the span predicate fails) since the trailing iterator will advance the underlying iterator. It would also be possible to leave the failing element in the leading lookahead buffer, where it would forever fail the predicate, but that entails evaluating the predicate twice, on both enqueue and dequeue.
* Merge pull request #4415 from Ichoran/issue/9254Adriaan Moors2015-04-221-0/+25
|\ | | | | SI-9254 UnrolledBuffer appends in wrong position
| * SI-9254 UnrolledBuffer appends in wrong positionRex Kerr2015-03-311-0/+25
| | | | | | | | | | | | | | | | | | | | | | Fixed two bugs in insertion (insertAll of Unrolled): 1. Incorrect recursion leading to an inability to insert past the first chunk 2. Incorect repositioning of `lastptr` leading to strange `append` behavior after early insertion Added tests checking that both of these things now work. Also added a comment that "waterlineDelim" is misnamed. But we can't fix it now--it's part of the public API. (Shouldn't be, but it is.)
* | Merge pull request #4416 from Ichoran/issue/9197Adriaan Moors2015-04-221-0/+24
|\ \ | | | | | | SI-9197 Duration.Inf not a singleton when deserialized
| * | SI-9197 Duration.Inf not a singleton when deserializedRex Kerr2015-03-311-0/+24
| |/ | | | | | | | | | | | | | | Made `Duration.Undefined`, `.Inf`, and `.MinusInf` all give back the singleton instance instead of creating a new copy by overriding readResolve. This override can be (and is) private, which at least on Sun's JDK8 doesn't mess with the auto-generated SerialVersionUIDs. Thus, the patch should make things strictly better: if you're on 2.11.7+ on JVMs which pick the same SerialVersionUIDs, you can recover singletons. Everywhere else you were already in trouble anyway.
* | Merge pull request #4462 from som-snytt/issue/badtabAdriaan Moors2015-04-221-0/+20
|\ \ | | | | | | SI-9275 Fix row-first display in REPL
| * | SI-9275 Fix row-first display in REPLSom Snytt2015-04-211-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | A missing range check in case anyone ever wants to use ``` -Dscala.repl.format=across ``` which was observed only because of competition from Ammonite.
* | | Merge pull request #4461 from adriaanm/rebase-4446Adriaan Moors2015-04-221-1/+1
|\ \ \ | | | | | | | | Fix many typos
| * | | 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.
* / / Remove stdout/stderr output from Junit testsJason Zaugg2015-04-211-1/+0
|/ /
* | Merge pull request #4431 from adriaanm/rebase-4379Adriaan Moors2015-04-131-3/+55
|\ \ | | | | | | Patmat: efficient reasoning about mutual exclusion
| * | Patmat: efficient reasoning about mutual exclusionGerard Basler2015-04-061-3/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Faster analysis of wide (but relatively flat) class hierarchies by using a more efficient encoding of mutual exclusion. The old CNF encoding for mutually exclusive symbols of a domain added a quadratic number of clauses to the formula to satisfy. E.g. if a domain has the symbols `a`, `b` and `c` then the clauses ``` !a \/ !b /\ !a \/ !c /\ !b \/ !c ``` were added. The first line prevents that `a` and `b` are both true at the same time, etc. There's a simple, more efficient encoding that can be used instead: consider a comparator circuit in hardware, that checks that out of `n` signals, at most 1 is true. Such a circuit can be built in the form of a sequential counter and thus requires only 3n-4 additional clauses [1]. A comprehensible comparison of different encodings can be found in [2]. [1]: http://www.carstensinz.de/papers/CP-2005.pdf [2]: http://www.wv.inf.tu-dresden.de/Publications/2013/report-13-04.pdf
* | | Merge pull request #4413 from lrytz/opt/inliningEverythingLukas Rytz2015-04-077-26/+92
|\ \ \ | |/ / |/| | Fixes and Improvements for the new inliner
| * | SI-9139 don't inline across @strictfp modesLukas Rytz2015-04-011-0/+21
| | | | | | | | | | | | Cannot inline if one of the methods is @strictfp, but not the other.
| * | Test case: cannot inline a private call into a different class.Lukas Rytz2015-04-011-0/+27
| | | | | | | | | | | | | | | Invocations of private methods cannot be inlined into a different class, this would cause an IllegalAccessError.
| * | Clean up the way compiler settings are accessed in the backend.Lukas Rytz2015-04-016-26/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Many backend components don't have access to the compiler instance holding the settings. Before this change, individual settings required in these parts of the backend were made available as members of trait BTypes, implemented in the subclass BTypesFromSymbols (which has access to global). This change exposes a single value of type ScalaSettings in the super trait BTypes, which gives access to all compiler settings.
| * | Don't try to inline native methodsLukas Rytz2015-04-011-0/+11
| | | | | | | | | | | | Because you can't, really.
| * | Eliminate unreachable code before inlining a methodLukas Rytz2015-04-012-1/+15
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Running an ASM analyzer returns null frames for unreachable instructions in the analyzed method. The inliner (and other components of the optimizer) require unreachable code to be eliminated to avoid null frames. Before this change, unreachable code was eliminated before building the call graph, but not again before inlining: the inliner assumed that methods in the call graph have no unreachable code. This invariant can break when inlining a method. Example: def f = throw e def g = f; println() When building the call graph, both f and g contain no unreachable code. After inlining f, the println() call becomes unreachable. This breaks the inliner's assumption if it tries to inline a call to g. This change intruduces a cache to remember methods that have no unreachable code. This allows invoking DCE every time no dead code is required, and bail out fast. This also simplifies following the control flow in the optimizer (call DCE whenever no dead code is required).
* | Merge pull request #4370 from gbasler/ticket/SI-9181Adriaan Moors2015-04-061-0/+3
|\ \ | |/ |/| SI-9181 Exhaustivity checking does not scale (regression)
| * Add a check to ensure that if the formulas originating from the exhaustivity /Gerard Basler2015-03-021-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 #4318 from soc/topic/remove-deprecation-warningsLukas Rytz2015-03-281-2/+2
|\ \ | | | | | | Remove deprecation warnings
| * | new{Term,Type}Name→{Term,Type}Name, tpename/nme→{type,term}NamesSimon Ochsenreither2015-03-261-2/+2
| | |
* | | SI-9038 fix scaladoc syntax highlightning to leave unicode aloneAntoine Gourlay2015-03-261-0/+22
|/ / | | | | | | | | | | | | | | Syntax highlightning in code blocks used to manipulate the raw bytes of a String, converting them to chars when needed, which breaks Unicode surrogate pairs. Using a char array instead of a byte array will leave them alone.
* | Don't inline methods containing super calls into other classesLukas Rytz2015-03-122-13/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | Method bodies that contain a super call cannot be inlined into other classes. The same goes for methods containing calls to private methods, but that was already ensured before by accessibility checks. The last case of `invokespecial` instructions is constructor calls. Those can be safely moved into different classes (as long as the constructor is accessible at the new location). Note that scalac never emits methods / constructors as private in bytecode.
generated by cgit v1.2.3 (git 2.39.1) at 2024-09-15 18:00:05 +0000