summaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #4563 from adriaanm/jline-shadeAdriaan Moors2015-06-1915-273/+334
|\ | | | | Corral, shade & embed jline.
| * SI-9339 Support classpaths with no single compatible jlineAdriaan Moors2015-06-185-11/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As usual, the repl will use whatever jline 2 jar on the classpath, if there is one. Failing that, there's a fallback and an override. If instantiating the standard `jline.InteractiveReader` fails, we fall back to an embedded, shaded, version of jline, provided by `jline_embedded.InteractiveReader`. (Assume `import scala.tools.nsc.interpreter._` for this message.) The instantiation of `InteractiveReader` eagerly exercises jline, so that a linkage error will result if jline is missing or if the provided one is not binary compatible. The property `scala.repl.reader` overrides this behavior, if set to the FQN of a class that looks like `YourInteractiveReader` below. ``` class YourInteractiveReader(completer: () => Completion) extends InteractiveReader ``` The repl logs which classes it tried to instantiate under `-Ydebug`. # Changes to source & build The core of the repl (`src/repl`) no longer depends on jline. The jline interface is now in `src/repl-jline`. The embedded jline + our interface to it are generated by the `quick.repl` target. The build now also enforces that only `src/repl-jline` depends on jline. The sources in `src/repl` are now sure to be independent of it, though they do use reflection to instantiate a suitable subclass of `InteractiveReader`, as explained above. The `quick.repl` target builds the sources in `src/repl` and `src/repl-jline`, producing a jar for the `repl-jline` classes, which is then transformed using jarjar to obtain a shaded copy of the `scala.tools.nsc.interpreter.jline` package. Jarjar is used to combine the `jline` jar and the `repl-jline` into a new jar, rewriting package names as follows: - `org.fusesource` -> `scala.tools.fusesource_embedded` - `jline` -> `scala.tools.jline_embedded` - `scala.tools.nsc.interpreter.jline` -> `scala.tools.nsc.interpreter.jline_embedded` Classes not reachable from `scala.tools.**` are pruned, as well as empty dirs. The classes in the `repl-jline` jar as well as those in the rewritten one are copied to the repl's output directory. PS: The sbt build is not updated, sorry. PPS: A more recent fork of jarjar: https://github.com/shevek/jarjar.
| * Centralize dependencies on jlineAdriaan Moors2015-06-1715-273/+314
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Code that depends on jline is now in package `scala.tools.nsc.interpreter.jline`. To make this possible, remove the `entries` functionality from `History`, and add the `historicize` method. Also provide an overload for `asStrings`. Clean up a little along the way in `JLineHistory.scala` and `JLineReader.scala`. Next step: fall back to an embedded jline when the expected jline jar is not on the classpath. The gist of the refactor: https://gist.github.com/adriaanm/02e110d4da0a585480c1
* | Merge pull request #4331 from Ichoran/issue/8930Adriaan Moors2015-06-191-5/+12
|\ \ | | | | | | SI-8930 - Vector updated, +:, and :+ slow when typed as Seq[A]
| * | SI-8930 - Vector updated, +:, and :+ slow when typed as Seq[A]Rex Kerr2015-06-181-5/+12
| | | | | | | | | | | | | | | | | | Vector was intercepting only the IndexedSeq CanBuildFrom to quickly generate new vectors. Now it intercepts immutable.Seq and collection.Seq as well. There are other possibilities (collection.IndexedSeq), but they will probably arise rarely, and to avoid an absurdly long set of checks we would need a marker trait (that is not binary compatible).
* | | Merge pull request #4559 from janekdb/2.11.x-scaladoc-2Seth Tisue2015-06-1811-17/+17
|\ \ \ | | | | | | | | Fix some typos (a-c)
| * | | Fix another several typosMichaƂ Pociecha2015-06-185-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | 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-189-10/+10
| | | |
* | | | Merge pull request #4529 from lrytz/inlineAccessibilityJason Zaugg2015-06-192-18/+74
|\ \ \ \ | | | | | | | | | | Fix illegal inlining of instructions accessing protected members
| * | | | Fix illegal inlining of instructions accessing protected membersLukas Rytz2015-05-282-18/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 #4543 from som-snytt/issue/7773Seth Tisue2015-06-181-10/+12
|\ \ \ \ \ | | | | | | | | | | | | SI-7773 Restore phase id to icode filename
| * | | | | SI-7773 Restore phase id to icode filenameSom Snytt2015-06-071-10/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Having icode output files of the form `X-24.icode` went in and out of style using the long-form phase name because it broke the windows nightly build somehow. Here's hoping using just the phase id works on this year's infrastructure. As previously, the long name is still available under `-Ydebug`, because why not debug.
* | | | | | Merge pull request #4539 from vsalvis/vsalvis-docfixesSeth Tisue2015-06-186-31/+12
|\ \ \ \ \ \ | | | | | | | | | | | | | | Doc fixes
| * | | | | | SI-6131 doc: remove broken show member link from all scaladoc pagesvsalvis2015-06-171-1/+0
| | | | | | |
| * | | | | | SI-8543 doc: Move TODO out of NumericRange's scaladocvsalvis2015-06-171-4/+4
| | | | | | |
| * | | | | | SI-8858 doc: fix note about PartialFunction in Function0, F1 and F2vsalvis2015-06-174-26/+8
| |/ / / / /
* | | | | | Merge pull request #4553 from som-snytt/issue/implicit-docSeth Tisue2015-06-182-2/+12
|\ \ \ \ \ \ | |_|_|/ / / |/| | | | | SI-9354 ScalaDoc members added via by-name view
| * | | | | SI-9354 ScalaDoc members added via by-name viewSom Snytt2015-06-142-2/+12
| |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Eligible views were looked up by exact from type without including the by-name dodge. By-name views are now included without consideration whether ScalaDoc processes possible duplicates correctly.
* | | | | Merge pull request #4527 from nicky-zs/fix_BigDecimalLukas Rytz2015-06-181-2/+2
|\ \ \ \ \ | |_|_|/ / |/| | | | fix BigDecimal losing MathContext
| * | | | fix BigDecimal loosing MathContextZhong Sheng2015-05-271-2/+2
| | | | |
* | | | | Merge pull request #4560 from adriaanm/t9356Adriaan Moors2015-06-171-11/+9
|\ \ \ \ \ | | | | | | | | | | | | SI-9356 more careful assertion in back-end
| * | | | | SI-9356 more careful assertion in back-endAdriaan Moors2015-06-161-11/+9
| | |_|_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | | | Merge pull request #4558 from janekdb/2.11.x-scaladoc-1-list-buffer-tryAdriaan Moors2015-06-172-2/+2
|\ \ \ \ \ | | | | | | | | | | | | Improve API documentation for ListBuffer and Try
| * | | | | Improve API documentation for ListBuffer and TryJanek Bogucki2015-06-162-2/+2
| | | | | |
* | | | | | Merge pull request #4541 from vuakko/SI-9348_2.11.xAdriaan Moors2015-06-171-3/+3
|\ \ \ \ \ \ | | | | | | | | | | | | | | SI-9348 Fix missing last element in exclusive floating point ranges
| * | | | | | SI-9348 Fix missing last element in exclusive floating point rangesNiko Vuokko2015-06-171-3/+3
| | |/ / / / | |/| | | | | | | | | | | | | | | | | | | | | | 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 #4545 from retronym/topic/constr-varargs-toolboxAdriaan Moors2015-06-171-0/+1
|\ \ \ \ \ \ | | | | | | | | | | | | | | Fix toolbox with varargs constructors
| * | | | | | SI-9212 Fix toolbox with varargs constructorsJason Zaugg2015-06-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | It was already working for methods, but not for constructors.
* | | | | | | Merge pull request #4420 from Ichoran/issue/8254Adriaan Moors2015-06-171-0/+2
|\ \ \ \ \ \ \ | |_|/ / / / / |/| | | | | | SI-8254 List SerializationProxy fails to default(Read/Write)Object
| * | | | | | SI-8254 List SerializationProxy fails to default(Read/Write)ObjectRex Kerr2015-03-311-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Added `defaultWriteObject` to the beginning of `writeObject` and `defaultReadObject` to the beginning of `readObject` as required by specs: [writing](http://docs.oracle.com/javase/6/docs/platform/serialization/spec/output.html#861), [reading](http://docs.oracle.com/javase/6/docs/platform/serialization/spec/input.html#2971). Verified that it is a no-op in terms of serialization stream (but it provides hooks that Infinispan and others may use). No explicit tests. If there is a change in serialization, t8549 will catch it.
* | | | | | | Merge pull request #4534 from Ichoran/sorting-reimplAdriaan Moors2015-06-161-477/+235
|\ \ \ \ \ \ \ | |_|_|/ / / / |/| | | | | | Clean implementation of sorts for scala.util.Sorting.
| * | | | | | Clean implementation of sorts for scala.util.Sorting.Rex Kerr2015-06-011-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 #4548 from ScrapCodes/git_4522Jason Zaugg2015-06-142-16/+56
|\ \ \ \ \ \ \ | |_|_|/ / / / |/| | | | | | SI-7747 Make REPL wrappers serialization friendly.
| * | | | | | SI-7747 More tests and logic according to our conclusions on #4522.Prashant Sharma2015-06-101-4/+4
| | | | | | |
| * | | | | | SI-7747 Limit previous change to imports of REPL valsJason Zaugg2015-05-261-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We only need to introduce the temporary val in the imports wrapper when we are importing a val or module defined in the REPL. The test case from the previous commit still passes, but we are generating slightly simpler code. Compared to 2.11.6, these two commits result in the following diff: https://gist.github.com/retronym/aa4bd3aeef1ab1b85fe9
| * | | | | | SI-7747 Make REPL wrappers serialization friendlyPrashant Sharma2015-05-262-16/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Spark has been shipping a forked version of our REPL for sometime. We have been trying to fold the patches back into the mainline so they can defork. This is the last outstanding issue. Consider this REPL session: ``` scala> val x = StdIn.readInt scala> class A(a: Int) scala> serializedAndExecuteRemotely { () => new A(x) } ``` As shown by the enclosed test, the REPL, even with the Spark friendly option `-Yrepl-class-based`, will re-initialize `x` on the remote system. This test simulates this by running a REPL session, and then deserializing the resulting closure into a fresh classloader based on the class files generated by that session. Before this patch, it printed "evaluating x" twice. This is based on the Spark change described: https://github.com/mesos/spark/pull/535#discussion_r3541925 A followup commit will avoid the `val lineN$read = ` part if we import classes or type aliases only. [Original commit from Prashant Sharma, test case from Jason Zaugg]
* | | | | | | Merge pull request #4536 from danieldietrich/2.11.xJason Zaugg2015-06-071-4/+5
|\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | Applying inverse index instead of reversing a List
| * | | | | | | Better names for length valuesDaniel Dietrich2015-06-051-5/+5
| | | | | | | |
| * | | | | | | Applying inverse index instead of reversing a ListDaniel Dietrich2015-06-021-1/+2
| | |/ / / / / | |/| | | | |
* | | | | | | Merge pull request #4519 from lrytz/opt/nullness-2.11Jason Zaugg2015-06-078-22/+1113
|\ \ \ \ \ \ \ | |_|_|_|_|/ / |/| | | | | | Nullness Analysis for GenBCode
| * | | | | | Fix aliasing / nullness of CHECKCASTLukas Rytz2015-06-042-3/+4
| | | | | | |
| * | | | | | Compiler option for disabling nullness analysisLukas Rytz2015-06-044-9/+23
| | | | | | |
| * | | | | | Address review feedbackLukas Rytz2015-05-253-60/+100
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Address feedback in #4516 / 57b8da4cd8. Save allocations of NullnessValue - there's only 4 possible instances. Also save tuple allocations in InstructionStackEffect.
| * | | | | | Fix wrong result in InstructionStackEffect for ATHROW, RETURNLukas Rytz2015-05-251-3/+3
| | | | | | |
| * | | | | | Fix wrong indexing in FrameExtensions.peekStackLukas Rytz2015-05-251-1/+1
| | | | | | |
| * | | | | | Enable nullness analysis in the inlinerLukas Rytz2015-05-252-12/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-226-7/+1031
| | |_|_|_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-9343 Xlint less strict on pattern sequencesSom Snytt2015-06-031-2/+4
| |/ / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -Xlint:stars-align warns only if elementarity > 0, that is, if an extracted sequence is not matched entirely by a pattern sequence, that is, in SLS 8.1.9 on pattern sequences, n = 1 and that pattern is a pattern sequence. This is still only triggered if productarity > 0, that is, a non-pattern-sequence pattern is required for the match. This is a sensitive area because it borders on exhaustiveness checking: it would be preferable to verify just that the match is exhaustive, and to emit this warning only if it is not.
* | | | | Merge pull request #4511 from sriggin/SI-9322Lukas Rytz2015-05-282-3/+3
|\ \ \ \ \ | | | | | | | | | | | | SI-9322 Elapsed times in compiler calculated with System.currentTimeMillis and System.nanoTime
| * | | | | SI-9322 Elapsed times in compiler calculated withSean Riggin2015-05-262-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | System.currentTimeMillis and System.nanoTime Reverted elapsedTime calculation in compiler to use System.currentTimeMillis, consistent with the start time.