summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* SI-8786 fix generic signature for @varargs forwarder methodsLukas Rytz2017-01-0910-92/+247
| | | | | | | | | | | | | | | | | | | | | | | | | When generating a varargs forwarder for def foo[T](a: T*) the parameter type of the forwarder needs to be Array[Object]. If we generate Array[T] in UnCurry, that would be erased to plain Object, and the method would not be a valid varargs. Unfortunately, setting the parameter type to Array[Object] lead to an invalid generic signature - the generic signature should reflect the real signature. This change adds an attachment to the parameter symbol in the varargs forwarder method and special-cases signature generation. Also cleans up the code to produce the varargs forwarder. For example, type parameter and parameter symbols in the forwarder's method type were not clones, but the same symbols from the original method were re-used. Backported from 0d2760dce189cdcb363e54868381175af4b2646f, with a small tweak (checkVarargs) to make the test work on Java 6, as well as later versions.
* support --show-log for partest commandAdriaan Moors2017-01-091-1/+1
|
* Merge pull request #5615 from ↵Stefan Zeiger2017-01-094-11/+102
|\ | | | | | | | | monkey-mas/modify-ArrayBuilder-reusability-bug-2016-12-24 [Backport] Modify ArrayBuilder and WrappedArrayBuilder to be reusable
| * [Backport] Modify ArrayBuilder and WrappedArrayBuilder to be reusableMasaru Nomura2016-12-284-11/+102
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As they're reusable in 2.12.x with this change[1], it'd be useful to make them reusable in 2.11.x. [1] https://github.com/scala/scala/commit/6eaae1b969b68ed3dc65a40613a8168b09246256 With this change, not only are they reusable but also we can avoid mutation of previously created arrays. Behaviour(Problem): Actual behaviour before this modification is as follows; <ArrayBuilder> ``` scala> import scala.collection.mutable.ArrayBuilder import scala.collection.mutable.ArrayBuilder scala> val builder = new ArrayBuilder.ofInt builder: scala.collection.mutable.ArrayBuilder.ofInt = ArrayBuilder.ofInt scala> builder ++= Vector.range(1, 17) res0: builder.type = ArrayBuilder.ofInt scala> val arr = builder.result() arr: Array[Int] = Array(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16) scala> builder.clear() scala> builder += 100 res2: builder.type = ArrayBuilder.ofInt scala> val arr2 = builder.result() arr2: Array[Int] = Array(100) scala> arr res3: Array[Int] = Array(100, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16) // arr should be Array(1, .., 16) but was unexpectedly mutated by `+=` operation ``` `arr` was mutated as follows; 1. `result` & `clear` - `arr = elems` - `size = 0` 2. `+=(100)` - `ensureSize(0 + 1)` => `capacity < size || capacity == 0` is `false` as `capacity == 16` and `size == 1` - `elems(0) = 100` this is where `arr(0) = 100` was done because we did not reallocate a new array for `elems` when calling `ensureSize`, which should have happened. - `size = 1` 3. `result` - `mkArray(1)` gives us `arr2 = Array(100)` <WrappedArrayBuilder> We can observe almost the same mutation behaviour of ArrayBuilder. ``` scala> import scala.collection.mutable.WrappedArray import scala.collection.mutable.WrappedArray scala> import scala.collection.mutable.WrappedArrayBuilder import scala.collection.mutable.WrappedArrayBuilder scala> import scala.reflect.ClassTag import scala.reflect.ClassTag scala> val builder = new WrappedArrayBuilder(ClassTag.Int) builder: scala.collection.mutable.WrappedArrayBuilder[Int] = scala.collection.mutable.WrappedArrayBuilder@56cbfb61 scala> builder ++= Vector.range(1, 17) res0: builder.type = scala.collection.mutable.WrappedArrayBuilder@56cbfb61 scala> builder.result() res1: scala.collection.mutable.WrappedArray[Int] = WrappedArray(1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16) scala> builder.clear() scala> builder += 100 res3: builder.type = scala.collection.mutable.WrappedArrayBuilder@56cbfb61 scala> res1 res4: scala.collection.mutable.WrappedArray[Int] = WrappedArray(100, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16) scala> builder.result() res5: scala.collection.mutable.WrappedArray[Int] = WrappedArray(100) ``` Solution: We should reset `capacity` to `0` when calling `result` so that `ensureSize(1)` calls `resize(16)`, which satisfies the property of Builder reusability. Besides mutation of previously created arrays does not happen.
* | Merge pull request #5626 from adriaanm/rebase-5566Adriaan Moors2017-01-056-78/+66
|\ \ | | | | | | [backport] Hash table getOrElseUpdate and indexing
| * | Simplify HashTable.index furtherPap Lőrinc2017-01-051-6/+2
| | | | | | | | | | | | (cherry picked from commit 26c87f1af4cac782911500d6b143681ecdcef8ad)
| * | Changed HashMap.getOrElseUpdate to only calculate the index oncePap Lőrinc2017-01-051-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes https://issues.scala-lang.org/browse/SI-10049 Since `groupBy` uses this method extensively and suffered a measurable slowdown in `2.12.0`, this modification restores (and exceeds) its original speed. --- included benchmarks: (`ns/op` → smaller is better) `before (2.12.0):` ```java Benchmark (size) Mode Cnt Score Error Units s.c.immutable.VectorMapBenchmark.groupBy 10 avgt 20 865.693 ± 7.869 ns/op s.c.immutable.VectorMapBenchmark.groupBy 100 avgt 20 3095.657 ± 56.438 ns/op s.c.immutable.VectorMapBenchmark.groupBy 1000 avgt 20 28247.005 ± 470.513 ns/op s.c.mutable.HashMapBenchmark.get 10 avgt 20 679.448 ± 11.809 ns/op s.c.mutable.HashMapBenchmark.get 100 avgt 20 7240.178 ± 61.734 ns/op s.c.mutable.HashMapBenchmark.get 1000 avgt 20 95725.127 ± 2373.458 ns/op s.c.mutable.HashMapBenchmark.getOrElseUpdate 10 avgt 20 836.561 ± 20.085 ns/op s.c.mutable.HashMapBenchmark.getOrElseUpdate 100 avgt 20 7891.368 ± 56.808 ns/op s.c.mutable.HashMapBenchmark.getOrElseUpdate 1000 avgt 20 97478.629 ± 1782.497 ns/op s.c.mutable.HashMapBenchmark.put 10 avgt 20 243.422 ± 2.915 ns/op s.c.mutable.HashMapBenchmark.put 100 avgt 20 5810.927 ± 60.054 ns/op s.c.mutable.HashMapBenchmark.put 1000 avgt 20 82175.539 ± 1690.296 ns/op ``` `after:` ```java Benchmark (size) Mode Cnt Score Error Units s.c.immutable.VectorMapBenchmark.groupBy 10 avgt 20 627.007 ± 9.718 ns/op s.c.immutable.VectorMapBenchmark.groupBy 100 avgt 20 2086.955 ± 19.042 ns/op s.c.immutable.VectorMapBenchmark.groupBy 1000 avgt 20 19515.234 ± 173.647 ns/op s.c.mutable.HashMapBenchmark.get 10 avgt 20 683.977 ± 11.843 ns/op s.c.mutable.HashMapBenchmark.get 100 avgt 20 7345.675 ± 41.092 ns/op s.c.mutable.HashMapBenchmark.get 1000 avgt 20 95085.926 ± 1702.997 ns/op s.c.mutable.HashMapBenchmark.getOrElseUpdate 10 avgt 20 503.208 ± 2.643 ns/op s.c.mutable.HashMapBenchmark.getOrElseUpdate 100 avgt 20 5526.483 ± 28.262 ns/op s.c.mutable.HashMapBenchmark.getOrElseUpdate 1000 avgt 20 69265.900 ± 674.958 ns/op s.c.mutable.HashMapBenchmark.put 10 avgt 20 252.481 ± 7.597 ns/op s.c.mutable.HashMapBenchmark.put 100 avgt 20 5708.034 ± 110.360 ns/op s.c.mutable.HashMapBenchmark.put 1000 avgt 20 82051.378 ± 1432.009 ns/op ``` i.e. for the given benchmark conditions `~40%` faster `groupBy` and `getOrElseUpdate` (cherry picked from commit b67ca7dc6bb84758f9c9f64d68b0b11c20995aa0)
| * | Changed hashing bit rotation to use Integer.rotateRightPap Lőrinc2017-01-052-19/+8
| | | | | | | | | | | | (cherry picked from commit bc912230129d68466474bcc6c99356b44f65c3c2)
| * | Changed modulo to bitwise AND in hash calculationPap Lőrinc2017-01-051-52/+17
| | | | | | | | | | | | (cherry picked from commit 7952525e7119282ec8308a0076db54923f95dc21)
| * | Optimized HashTable.indexPap Lőrinc2017-01-051-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (`ops/s`, smaller is better) `Before (9c5d3f8)`: ```scala [info] # Run complete. Total time: 00:08:15 [info] [info] Benchmark (size) Mode Cnt Score Error Units [info] s.c.immutable.VectorMapBenchmark.groupBy 10 avgt 20 645.594 ± 9.435 ns/op [info] s.c.immutable.VectorMapBenchmark.groupBy 100 avgt 20 2084.216 ± 37.814 ns/op [info] s.c.immutable.VectorMapBenchmark.groupBy 1000 avgt 20 19878.481 ± 262.404 ns/op [info] s.c.mutable.HashMapBenchmark.get 10 avgt 20 689.941 ± 5.850 ns/op [info] s.c.mutable.HashMapBenchmark.get 100 avgt 20 7357.330 ± 45.956 ns/op [info] s.c.mutable.HashMapBenchmark.get 1000 avgt 20 95767.200 ± 1550.771 ns/op [info] s.c.mutable.HashMapBenchmark.getOrElseUpdate 10 avgt 20 509.181 ± 2.683 ns/op [info] s.c.mutable.HashMapBenchmark.getOrElseUpdate 100 avgt 20 5563.301 ± 32.335 ns/op [info] s.c.mutable.HashMapBenchmark.getOrElseUpdate 1000 avgt 20 71965.365 ± 1809.738 ns/op [info] s.c.mutable.HashMapBenchmark.put 10 avgt 20 247.270 ± 3.972 ns/op [info] s.c.mutable.HashMapBenchmark.put 100 avgt 20 5646.185 ± 106.172 ns/op [info] s.c.mutable.HashMapBenchmark.put 1000 avgt 20 81303.663 ± 954.938 ns/op ``` `Changed modulo to bitwise and in hash calculation (4c729fe)`: ```scala [info] Benchmark (size) Mode Cnt Score Error Units [info] s.c.immutable.VectorMapBenchmark.groupBy 10 avgt 20 631.291 ± 9.269 ns/op [info] s.c.immutable.VectorMapBenchmark.groupBy 100 avgt 20 2077.885 ± 59.737 ns/op [info] s.c.immutable.VectorMapBenchmark.groupBy 1000 avgt 20 15458.278 ± 317.347 ns/op [info] s.c.mutable.HashMapBenchmark.get 10 avgt 20 678.013 ± 4.453 ns/op [info] s.c.mutable.HashMapBenchmark.get 100 avgt 20 7258.522 ± 76.088 ns/op [info] s.c.mutable.HashMapBenchmark.get 1000 avgt 20 94748.845 ± 1226.120 ns/op [info] s.c.mutable.HashMapBenchmark.getOrElseUpdate 10 avgt 20 498.042 ± 5.006 ns/op [info] s.c.mutable.HashMapBenchmark.getOrElseUpdate 100 avgt 20 5243.154 ± 110.372 ns/op [info] s.c.mutable.HashMapBenchmark.getOrElseUpdate 1000 avgt 20 68194.752 ± 655.436 ns/op [info] s.c.mutable.HashMapBenchmark.put 10 avgt 20 257.275 ± 1.411 ns/op [info] s.c.mutable.HashMapBenchmark.put 100 avgt 20 5318.532 ± 152.923 ns/op [info] s.c.mutable.HashMapBenchmark.put 1000 avgt 20 79607.160 ± 651.779 ns/op ``` `Optimized HashTable.index (6cc1504)`: ```scala [info] Benchmark (size) Mode Cnt Score Error Units [info] s.c.immutable.VectorMapBenchmark.groupBy 10 avgt 20 616.164 ± 4.712 ns/op [info] s.c.immutable.VectorMapBenchmark.groupBy 100 avgt 20 2034.447 ± 14.495 ns/op [info] s.c.immutable.VectorMapBenchmark.groupBy 1000 avgt 20 14712.164 ± 119.983 ns/op [info] s.c.mutable.HashMapBenchmark.get 10 avgt 20 679.046 ± 6.872 ns/op [info] s.c.mutable.HashMapBenchmark.get 100 avgt 20 7242.097 ± 41.244 ns/op [info] s.c.mutable.HashMapBenchmark.get 1000 avgt 20 95342.919 ± 1521.328 ns/op [info] s.c.mutable.HashMapBenchmark.getOrElseUpdate 10 avgt 20 488.034 ± 4.554 ns/op [info] s.c.mutable.HashMapBenchmark.getOrElseUpdate 100 avgt 20 4883.123 ± 59.268 ns/op [info] s.c.mutable.HashMapBenchmark.getOrElseUpdate 1000 avgt 20 65174.034 ± 496.759 ns/op [info] s.c.mutable.HashMapBenchmark.put 10 avgt 20 267.983 ± 1.797 ns/op [info] s.c.mutable.HashMapBenchmark.put 100 avgt 20 5097.351 ± 104.538 ns/op [info] s.c.mutable.HashMapBenchmark.put 1000 avgt 20 78772.540 ± 543.935 ns/op ``` Summary, i.e. the effect of this PR, according to the benchmarks: * `groupBy` has a `~35%` speedup * `get` didn't change * `getOrElseUpdate` has a `~10%` speedup * `put` has a `~3%` speedup Note: caching the `exponent` to a local private field (`Byte` or `Int`) didn't have any performance advantage (only a minor slowdown was measured, possibly because it's accessed via an interface now) (cherry picked from commit a5014447861a5678c8b595e235019bb8fec098a7)
| * | SI-8774 Null link fields in mutable hash maps on removal.Carsten Varming2017-01-053-1/+8
| | | | | | | | | | | | (cherry picked from commit 9a2486087a9739108265e7830ebaa96373605d02)
| * | Restarr on 2.11.8-18269eaAdriaan Moors2017-01-051-1/+1
|/ /
* | Merge pull request #5612 from adriaanm/patmat_cleanupAdriaan Moors2017-01-0414-32/+139
|\ \ | | | | | | Cleanup in aisle patmat
| * | SI-9630 Fix spurious warning related to same-named case accessors [backport]Jason Zaugg2016-12-2111-7/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hash consing of trees within pattern match analysis was broken, and considered `x1.foo#1` to be the same tree as `x1.foo#2`, even though the two `foo`-s referred to different symbols. The hash consing was based on `Tree#correspondsStructure`, but the predicate in that function cannot veto correspondance, it can only supplement the default structural comparison. I've instead created a custom tree comparison method for use in the pattern matcher that handles the tree shapes that we use. (cherry picked from commit 79a52e6807d2797dee12bab1730765441a0e222d)
| * | More robust outer test for patmatAdriaan Moors2016-12-211-10/+8
| | | | | | | | | | | | While investigating https://github.com/scala/scala-dev/issues/251
| * | Small cleanups to pattern matcherAdriaan Moors2016-12-212-15/+19
| |/ | | | | | | While investigating https://github.com/scala/scala-dev/issues/251
* | Merge pull request #5624 from Jasper-M/patch-1Lukas Rytz2017-01-031-1/+1
|\ \ | |/ |/| Fix documentation of immutable.Queue
| * Fix documentation of immutable.QueueJasper-M2017-01-031-1/+1
|/ | | `enqueue` appends elements to the `Queue`, it doesn't prepend them.
* Merge pull request #5605 from szeiger/wip/fix-07-linksAdriaan Moors2016-12-192-4/+4
|\ | | | | Fix spec links to `07-implicits.html`
| * Fix spec links to `07-implicits.html`Stefan Zeiger2016-12-182-4/+4
| | | | | | | | | | The file referenced by the current links actually exists under http://www.scala-lang.org/files/archive/spec/2.11/ but with a different design than the rest. It seems to be left over from an older version.
* | Merge pull request #5604 from sjrd/scalajs-friendly-assertthrowsLukas Rytz2016-12-171-5/+4
|\ \ | | | | | | Use ClassTag instead of Manifest in AssertUtil.assertThrows.
| * | Use ClassTag instead of Manifest in AssertUtil.assertThrows.Sébastien Doeraene2016-12-171-5/+4
|/ / | | | | | | | | This allows it to work in Scala.js, which supports `ClassTag`s but not `Manifest`s.
* | Merge pull request #5487 from lrytz/java-constantsAdriaan Moors2016-12-1522-2/+341
|\ \ | | | | | | SI-3236 constant types for literal final static java fields
| * | neg test for parsing constants in Java sourcesLukas Rytz2016-11-027-0/+104
| | |
| * | Support implicit converstions from java literalsLukas Rytz2016-11-021-38/+41
| | | | | | | | | | | | | | | | | | | | | | | | For example, public static final byte b = 127 is allowed, but 128 is not. Also factor out a method that parses a literal. It could be used to parse annotations (and their literal arguments) in Java sources.
| * | SI-3236 constant types for literal final static java fieldsJohannes Rudolph2016-10-2815-2/+234
| | | | | | | | | | | | | | | | | | | | | | | | | | | Since we don't parse Java expressions, fields of Java classes coming from source files never have constant types. This prevents using static java fields in annotation arguments in mixed compilation This PR assigns constant types to final static java fields if the initializer is a simple literal.
* | | Merge pull request #5454 from som-snytt/issue/9834-2.11Adriaan Moors2016-12-157-16/+78
|\ \ \ | | | | | | | | SI-9834 Improve error on failed op=
| * | | SI-9834 Show expansion of update on errorSom Snytt2016-11-252-3/+5
| | | |
| * | | SI-9834 Improve error on failed op=Som Snytt2016-11-257-16/+76
| | |/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If rewriting `x += y` fails to typecheck, emit error messages for both the original tree and the assignment. If rewrite is not attempted because `x` is a val, then say so. The error message at `tree.pos` is updated with the additional advice. SI-8763 Crash in update conversion When there are already errors, don't attempt mechanical rewrites.
* | | Merge pull request #5590 from 2m/mima-0.1.13-scala-2.11Seth Tisue2016-12-123-26/+2
|\ \ \ | | | | | | | | Upgrade MiMa to 0.1.13
| * | | Upgrade MiMa to 0.1.13Martynas Mickevičius2016-12-083-26/+2
| | | |
* | | | Merge pull request #5574 from ptrcarta/patch-1Lukas Rytz2016-12-121-1/+1
|\ \ \ \ | | | | | | | | | | fix eBNF error by removing wrong closing brace
| * | | | fix eBNF error by removing wrong closing braceptrcarta2016-12-021-1/+1
| |/ / /
* / / / SI-10086 NumericRange.min|max with custom Integral (#5575)Tobias Schlatter2016-12-122-2/+46
|/ / / | | | | | | SI-10086 NumericRange.min|max with custom Integral
* | | Merge pull request #5571 from SethTisue/mima-upgradeSeth Tisue2016-12-014-2/+263
|\ \ \ | | | | | | | | upgrade MiMa to 0.1.12
| * | | upgrade MiMa to 0.1.12Seth Tisue2016-12-014-2/+263
|/ / / | | | | | | | | | | | | dogfooding the latest. upgrading all the way from 0.1.8 -- there have been a bunch of improvements since then.
* | | Update to mathjax 2.6-latest [2.12.x backport]Adriaan Moors2016-11-291-1/+1
| | | | | | | | | | | | This fixes the vertical bar problem on Chrome (https://github.com/mathjax/MathJax/issues/1300);
* | | Merge pull request #5553 from retronym/ticket/SD-271Jason Zaugg2016-11-292-1/+10
|\ \ \ | | | | | | | | Improve performance of REPL autocompletion
| * | | Improve performance of REPL autocompletionJason Zaugg2016-11-222-1/+10
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The code used to fuzzily match, e.g, `declasses` with `getDeclaredClasses` was exploring fruitless parts of the search space. The enclosed test case was hanging the REPL. This commit improves this by performing a prefix match of the unconsumed input against the current chunk of the candidate before exploring the `inits`. Fixes scala/scala-dev#271
* | | Merge pull request #5559 from szeiger/wip/mathjax-httpsAdriaan Moors2016-11-281-2/+2
|\ \ \ | |/ / |/| | Use https links to JS and CSS in the spec when serving from https
| * | Use https links to JS and CSS in the spec when serving from httpsStefan Zeiger2016-11-281-2/+2
|/ / | | | | | | | | | | | | | | | | | | The spec is published on a server that supports https (https://www.scala-lang.org/files/archive/spec/2.11/) and this comes up as the default in search results (as it should) but the link to MathJAX is hardcoded to http, which prevents any web browser that cares about security from loading it. This commit changes the links to MathJAX and to the Highlight.js stylesheet to be scheme-relative (like the link to JQuery already was).
* | Merge pull request #5518 from som-snytt/issue/10037-2.11Jason Zaugg2016-11-116-5/+23
|\ \ | | | | | | SI-10037 ASR/LSR switched in ICodeReader
| * | [nomerge] SI-10037 ASR/LSR switched in ICodeReaderSom Snytt2016-11-106-5/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Noticed when inlining from a class file. The test doesn't work because inlining fails with bytecode unavailable due to: ``` scala.reflect.internal.MissingRequirementError: object X in compiler mirror not found. ```
* | | Merge pull request #5491 from SethTisue/akka-bumpSeth Tisue2016-11-101-1/+1
|\ \ \ | |/ / |/| | move to latest Akka 2.3.x release
| * | move to latest Akka 2.3.x releaseSeth Tisue2016-10-311-1/+1
| | | | | | | | | | | | | | | Akka 2.3.16 was released in October 2016: http://akka.io/news/2016/10/30/akka-2.3.16-released.html
* | | Merge pull request #5511 from SethTisue/stop-no-dont-delete-everything-arghSeth Tisue2016-11-081-1/+1
|\ \ \ | | | | | | | | don't mass-delete old nightlies at release time
| * | | don't mass-delete old nightlies at release timeSeth Tisue2016-11-081-1/+1
|/ / / | | | | | | | | | | | | | | | | | | as happened with 2.12.0, for gory details see https://github.com/scala/scala-dev/issues/257 fix suggested by Stefan Zeiger
* | | Merge pull request #5504 from retronym/topic/sbt-macro-warnSeth Tisue2016-11-071-0/+4
|\ \ \ | | | | | | | | Silence SBT logging about macros and incremental compilation.
| * | | Silence SBT logging about macros and incremental compilation.Jason Zaugg2016-11-071-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since upgrading to SBT 0.13.12, clean builds have incurred warnings like: Because JavaMirrors.scala contains a macro definition, the following dependencies are invalidated unconditionally: .... This commit disables this behaviour of the SBT incremental compiler in the library and reflect projects, as these aren't regular macros (the macro implementations are hard coded in the compiler in `FastTrack`) so the new behaviour isn't actually improving correctness of inc. compilation.
* | | | Merge pull request #5478 from dragos/backport/remove-println-SI-8717Adriaan Moors2016-10-283-6/+4
|\ \ \ \ | |_|_|/ |/| | | [backport] Replace println with log calls in BrowsingLoaders
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-11 20:22:22 +0000