summaryrefslogtreecommitdiff
path: root/test/junit
Commit message (Collapse)AuthorAgeFilesLines
* SI-9737 [no-merge] Backport stringOf ParIterableNicolas Stucki2016-06-031-0/+57
| | | | | | | | | | | | | | Cherry-picked c5f3d3f286ee5c26c8ddcf10f6878058e8f7e040 Edited comment: in stringOf, let GenIterable subsume both Iterable and ParIterable. This change is required for Scala.js compatibility as it does not support parallel collections. Conflicts: src/library/scala/runtime/ScalaRunTime.scala
* Merge pull request #5167 from martijnhoekstra/SI-9766Lukas Rytz2016-05-231-0/+18
|\ | | | | SI 9766 - allow ++ on empty ConcatIterator
| * SI-9766 - allow ++ on empty ConcatIteratorMartijn Hoekstra2016-05-211-0/+18
| |
* | SI-9688 Make merge in immutable HashMap1 work with null kv.Łukasz Gieroń2016-05-231-0/+48
|/ | | | | | | | The kv field of scala.collection.immutable.HashMap.HashMap1 can be null. This commit corrects the behavior of updated0 (which is on call path for merged) to work in such cases, instead of throwing NPE. Commit contains regression test.
* Merge pull request #4937 from szeiger/issue/9623-2.11Seth Tisue2016-02-081-0/+28
|\ | | | | SI-9623 Avoid unnecessary hasNext calls in JoinIterator & ConcatIterator
| * SI-9623 Avoid unnecessary hasNext calls in JoinIterator & ConcatIteratorStefan Zeiger2016-02-011-0/+28
| | | | | | | | | | | | | | | | | | | | | | These iterator implementations are used to concatenate two (JoinIterator) or more (ConcatIterator) other iterators with `++`. They used to perform many unnecessary calls to the child iterators’ `hasNext` methods. This improved state machine-based implementation reduces that number to the bare minimum, i.e. iterating over concatenated iterators with `foreach` calls the children's `hasNext` methods a total of (number of children) + (number of elements) times, the same as when iterating over all children separately.
* | SI-9534 Use BoxedUnit in all cases for creating Array[Unit]Stefan Zeiger2016-01-271-1/+11
|/ | | | | | | | Calling `wrap` or one of the higher-dimension Array factory methods on the `Manifest` for `Unit` led to an exception because it tried to use `void` as a primitive type. Unlike all other primitive Scala types, `Unit` needs to be boxed. The basic `newArray` method was not affected by this bug because it was already special-cased. The fix is to also special-case `arrayClass`.
* SI-9605 Searching does not use binary search for ArrayRui Gonçalves2016-01-121-0/+48
| | | | Binary search should be used for every `IndexedSeqLike` instance and not only for `IndexedSeq`. According the Scaladoc, it is `IndexedSeqLike` that guarantees "constant-time or near constant-time element access and length computation".
* SI-9581 Fix overflow on Vector take and drop methodsRui Gonçalves2015-12-061-0/+30
| | | | | | Fixes the index/length comparison in `Vector#take` and `Vector#drop` so that they handle all possible integer values. Given the collection's invariants `startIndex >= endIndex` and `0 >= startIndex, endIndex`, it is sufficient to change the arithmetic in the comparison as done in this commit to avoid overflows. As cases when `n <= 0` are handled beforehand, `endIndex - n` cannot overflow, contrary to `startIndex + n`. If without the danger of overflows the condition yields true, on the other hand, `startIndex + n` cannot overflow as it is smaller than `endIndex` (as the previous formulation of the condition shows).
* Merge pull request #4809 from wpopielarski/delambdafy-multiple-outputsJason Zaugg2015-11-131-0/+73
|\ | | | | Multi output problem with delambdafied compilation
| * Test addedwpopielarski2015-11-061-0/+73
| |
* | SI-9497 Fix SetLike#clear() default implementationRui Gonçalves2015-10-211-0/+26
|/ | | | When dealing with mutable collections, it is not safe to assume iterators will remain consistent when the collection is modified mid-traversal. The bug reported in SI-9497 is very similar to SI-7269, "ConcurrentModificationException when filtering converted Java HashMap". Then, only the `retain` method was fixed. This commit fixes `clear`, which had the same problem.
* Suppress unneeded import.Performant Data LLC2015-10-141-2/+2
|
* SI-9513 decrement "deleted" count in OpenHashMap.put() when slot reusedPerformant Data LLC2015-10-101-0/+42
|
* Improve presentation compilation of annotationsJason Zaugg2015-09-241-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | A trio of problems were hampering autocompletion of annotations. First, given that that annotation is written before the annotated member, it is very common to end parse incomplete code that has a floating annotation without an anotatee. The parser was discarding the annotations (ie, the modifiers) and emitting an `EmptyTree`. Second, the presetation compiler was only looking for annotations in the Modifiers of a member def, but after typechecking annotations are moved into the symbol. Third, if an annotation failed to typecheck, it was being discarded in place of `ErroneousAnnotation`. This commit: - modifies the parser to uses a dummy class- or type-def tree, instead of EmptyTree, which can carry the annotations. - updates the locator to look in the symbol annotations of the modifiers contains no annotations. - uses a separate instance of `ErroneousAnnotation` for each erroneous annotation, and stores the original tree in its `original` tree.
* Support completion in erroneous string interpolation.Jason Zaugg2015-09-241-0/+8
| | | | | | | | | | | | | | | In the code: ``` s"${fooo<CURSOR" ``` The parser treats `fooo` as a interpolator ID for the quote that we actually intend to end the interpolated string. Inserting a space (in addition to `__CURSOR__` that we already patch in to avoid parsing a partial identifier as a keyword), solves this problem.
* Merge pull request #4725 from retronym/topic/completely-2.11Lukas Rytz2015-09-211-0/+161
|\ | | | | Topic/completely 2.11
| * Fix REPL completion of symbolic identifiersJason Zaugg2015-09-101-1/+8
| | | | | | | | | | | | | | Recover part of the identifier that preceded the cursor from the source, rather than from the name in the `Select` node, which might contains an encoded name that differs in length from the one in source.
| * Fix completion for synthetic case modules and methodsJason Zaugg2015-09-101-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | I'm pretty sure the `isSynthetic` call added in 854de25ee6 should instead be `isArtifact`, so that's what I've implemented here. `isSynthetic` used to also filter out error symbols, which are created with the flags `SYNTHETIC | IS_ERROR`. I've added an addition test for `isError`, which was needed to keep the output of `presentation/scope-completion-import` unchanged. The checkfile for `presentation/callcc-interpreter` is modified to add the additional completion proposals: synthetic companion objects.
| * Hide some completion candidates on the first TABJason Zaugg2015-09-091-0/+9
| | | | | | | | | | | | When `foo.<TAB>`, assume you don't want to see the inherited members from Any_ and universally applicable extension methods like `ensuring`. Hitting <TAB> a second time includes them in the results.
| * More liberal matching in REPL autocompletionJason Zaugg2015-09-091-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For the SHIFT-impaired: you can just write everything in lowercase, (whisper-case?) and we'll try to DWYM. We treat capital letters that you *do* enter as significant, they can't match a lower case letter in an identifier. Modelled after IntellIJ's completion. I still don't fall into this mode if you enter an exact prefix of a candidate, but we might consider changing that. ``` scala> classOf[String].typ<TAB> getAnnotationsByType getComponentType getDeclaredAnnotationsByType getTypeName getTypeParameters scala> classOf[String].typN<TAB> scala> classOf[String].getTypeName res3: String = java.lang.String scala> def foo(s: str<TAB> scala> def foo(s: String String StringBuffer StringBuilder StringCanBuildFrom StringContext StringFormat StringIndexOutOfBoundsException scala> def foo(s: string<TAB> scala> def foo(s: String String StringBuffer StringBuilder StringCanBuildFrom StringContext StringFormat StringIndexOutOfBoundsException ```
| * Camel Case and JavaBean completionJason Zaugg2015-09-081-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is just too useful to leave on the cutting room floor. ``` scala> classOf[String].enclo<TAB> scala> classOf[String].getEnclosing getEnclosingClass getEnclosingConstructor getEnclosingMethod scala> classOf[String].simpl<TAB> scala> classOf[String].getSimpleName type X = global.TTWD<TAB> scala> type X = global.TypeTreeWithDeferredRefCheck ``` I revised the API of `matchingResults` as it was clunky to reuse the filtering on accessibility and term/type-ness while providing a custom name matcher.
| * Sort completion proposalsJason Zaugg2015-09-031-0/+3
| |
| * Don't offer `asInstanceOf` et al as completions in a fresh REPLJason Zaugg2015-09-031-0/+4
| | | | | | | | | | Trying harder to keep the synthetic interpretter wrapper classes behind the curtain
| * Add the prefix the autocompletion results (Scope-, TypeMember)Jason Zaugg2015-09-031-0/+3
| | | | | | | | | | This makes life easier for clients of these APIs, we use this to avoid passing this around in the wrapper result `TypeMembers`.
| * Use the presentation compiler to drive REPL tab completionJason Zaugg2015-09-021-0/+109
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The old implementation is still avaiable under a flag, but we'll remove it in due course. Design goal: - Push as much code in src/interactive as possible to enable reuse outside of the REPL - Don't entangle the REPL completion with JLine. The enclosed test case drives the REPL and autocompletion programatically. - Don't hard code UI choices, like how to render symbols or how to filter candidates. When completion is requested, we wrap the entered code into the same "interpreter wrapper" synthetic code as is done for regular execution. We then start a throwaway instance of the presentation compiler, which takes this as its one and only source file, and has a classpath formed from the REPL's classpath and the REPL's output directory (by default, this is in memory). We can then typecheck the tree, and find the position in the synthetic source corresponding to the cursor location. This is enough to use the new completion APIs in the presentation compiler to prepare a list of candidates. We go to extra lengths to allow completion of partially typed identifiers that appear to be keywords, e.g `global.def` should offer `definitions`. Two secret handshakes are included; move the the end of the line, type `// print<TAB>` and you'll see the post-typer tree. `// typeAt 4 6<TAB>` shows the type of the range position within the buffer. The enclosed unit test exercises most of the new functionality.
* | 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.
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-27 02:52:58 +0000