* zinc-lm-intergration/bring-back-a-piece-of-zinc: (90 commits)
Add scala-integration resolver
call it compiler-bridge_2.13
bump Scala bridge to use 2.13.0-RC1
Break the dependency on LM, and thus Ivy
Skip Scala 2.10 and Scala 2.11 components for JDK 11
Refactor compiler bridge unit test
Fix the several typos detected by github.com/client9/misspell
Got rid of multiple warnigns
include only scala-library into the boot classpath during run
Drop "final" modifier from private case classes, to prevent false positive. Refer https://issues.scala-lang.org/browse/SI-4440
Support scala 2.13.0-pre-* & 2.13.0-M1
Split compiler bridge tests to another subproject
Remove unused imports + variables
Add back, re-configure & re-enable Scalafmt
Use Scala 2.12.3
Remove any reference to `F0` and `F1`
Adapt Zinc to use the new LibraryManagement API
Fix ScalaFmt wiring
Add scalaCompiler variant that accepts ModuleID
Bump all the modules
...
We are fairly certain we can maintain source-compatibility of compiler bridge from 2.13.0-RC to 2.13.x.
See also https://github.com/sbt/zinc/issues/78 :)
This patch breaks the dependency that Zinc had on sbt's Library
Management (LM) library abstraction (sbt/librarymanagement) and thus,
transitively, on Ivy.
The reason Zinc depends on LM in the first place is to dynamically
download the compiler bridge sources JAR, which it then compiles in
order to bridge from binary-compatible Zinc to the never-binary-stable
(and most of the time source-compatible) compiler API.
From my research (that is, using GitHub Search) the only user of this
feature is sbt, with all other integrations (e.g. pants, bloop, mill)
providing the compiler bridge sources JAR directly (an alternative API
entry point).
Therefore the dependency on LM and that integration code could be
untangled from Zinc and moved into sbt. That would also give an
opportunity to move the code in LM (back) into sbt, which I also think
would be a good idea.
For now this patch leaves that integration code in the already existing
`zinc-ivy-integration` module, but which is now no longer a dependency
of any other module of Zinc, specifically it is no longer a dependency
of the `zinc` and `zincScripted` modules. I think, though,
zinc-ivy-integration should remain in the zinc repo, as a part of the
build, being tested in CI, until it's been moved (back) into sbt. I'd
be happy to take care of both the remaining move and removal tasks.
In order to allow removing LM, Ivy and zinc-ivy-integration as
transitive dependencies of Zinc, this patch has to make a breaking
change to the `ZincUtil` object in the zinc module. Despite it being
defined in the `sbt.internal.inc` package (i.e. not declared as public
API) ZincUtil is in fact a used (Scala) API of Zinc (usages discovered
via GitHub Search). Therefore I chose to leave the object in the zinc
module and only drop from the object the two methods that directly
depend on LM's API. Specifically (1) the `getDefaultBridgeModule`
method and (2) the `scalaCompiler` overload that depends on LM were
removed. These methods now live in a new `ZincLmUtil` object in
zinc-ivy-integration, which sbt can switch to using.
In terms of risk, from my research (GitHub Search) the only users of
those methods are sbt and bloop. I need to confirm but I think bloop
will be able to manage this breaking change (it looks it might be just
fallback usage? TBC). For sbt we don't actual support using new Zinc
with old sbt, so sbt can also just update its usage on its next release.
Any other usage risks being broken but given it's internal, non-public
API I think it's fair game.
The remaining changes are in the testing so that zinc-ivy-integration's
test suite continues to test its download-and-compile behaviour, while
the rest of Zinc switches to using the prebuilt compiler bridges,
reusing and generalising some pre-existing zincScripted code (as well as
re-wiring some modules) so it can be used by zinc's tests too.
The usingTerminal method synchronizes the JLine object which can lead to
deadlock if multiple threads call it. When we just to want to read the
attributes of the terminal, but not modify it, there doesn't seem to be
any reason to use a lock.
I was seeing a number of compiler warnings about the type parameter
Scope:
Settings.scala:55:12: type parameter Scope defined in trait Init shadows class Scope defined in package util. You may want to rename your type parameter, or possibly remove it.
I'm not sure why I wasn't seeing these before, but the fix is simple.
Although this is technically in the internal package, it is exposed to
users when they write a custom input task. I do not think that we should
prevent users/plugin authors from writing their own parser
implementations if there is a different library they prefer. By my
count, there are 21 implementations of this interface in sbt, so it's
unlikely that there is much benefit from a pattern matching perspective.
While the AnyLeft and AnyRight types are necessary to make the extension
class work, I don't want to leak the AnyLeft or AnyRight traits into the
public api. It wasn't neceessary to annotate `some`, but it's good
practice to annotate anything public anyway.
This refactors the compiler bridge unit test to use the normal Zinc facility,
namely AnalyzingCompiler that's built on Scala 2.12, but is capable of driving
the compiler bridge built on non-2.12.
This allows us to run the unit tests without any additional dependencies published for Scala 2.13.0-M5.
Fixes https://github.com/sbt/sbt/issues/3405
Ref https://github.com/scala/scala-xml/issues/195
sbt's `run` is emulated using a classloader trick that includes ScalaInstance as the parent classloader under the classpath. The problem is the ScalaInstance classloader currently contains both compiler, library, and their transitive JARs:
```scala
res0: Array[java.io.File] = Array(scala-library.jar, scala-compiler.jar, jline.jar, scala-reflect.jar, scala-xml_2.12.jar)
```
This could have been causing various issues, but most recently it showed up as wrong version of scala-xml getting prioritized over what's passed by the user.
1. new field loaderLibraryOnly is added to xsbti.ScalaInstance.
2. it is initialized to the library loader if the launcher creates it, otherwise create layered loader here.
This aims to isolate the library loader, and retain the perf.
Make sure that we generate valid ID (according to matches(ID, s)) so
that we properly test the new validID implementation.
And that's what led to the bug fix. :)
It turned up in profiling sessions. Previously, it used parser combinators
which are somewhat slow especially when the JVM is still cold.
The grammar for ID is simple enough to afford this handwritten parser.
* 1.0.x: (28 commits)
Split compiler bridge tests to another subproject
Implement compiler bridge for 2.13.0-M2
Add yourkit acknoledgement in the README
"sbt '++ 2.13.0-M2!' compile" does not work with sbt 1.0.0
Add header to cached hashing spec
Add headers to missing files
Fix#332: Add sbt-header back to the build
Update sbt-scalafmt to 1.12
Make classpath hashing more lightweight
Fix#442: Name hash of value class should include underlying type
source-dependencies/value-class-underlying: fix test
Ignore null in generic lambda tparams
Improve and make scripted parallel
Fix#436: Remove annoying log4j scripted exception
Fix#127: Use `unexpanded` name instead of `name`
Add pending test case for issue/127
source-dependencies / patMat-scope workaround
Fixes undercompilation on inheritance on same source
Add real reproduction case for sbt/zinc#417
Add trait-trait-212 for Scala 2.12.3
...
Conflicts:
internal/zinc-apiinfo/src/main/scala/sbt/internal/inc/ClassToAPI.scala
project/build.properties
zinc/src/main/scala/sbt/internal/inc/MixedAnalyzingCompiler.scala
The ClassToAPI conflict is due to:
* https://github.com/sbt/zinc/pull/393 (a 1.x PR), conflicting with
* https://github.com/sbt/zinc/pull/446 (a 1.0.x PR).
The build.properties conflict is due to different PRs bumping
sbt.version from 1.0.0 to 1.0.2 to 1.0.3. (#413, #418, #453).
The MixedAnalyzingCompiler conflict is due to:
* https://github.com/sbt/zinc/pull/427 (a 1.x PR), conflicting with
* https://github.com/sbt/zinc/pull/452 (a 1.0.x PR).
Splitting compiler bridge tests to another subproject because while the bridge itself can be compiled with just compiler-interface, util-interface, and Scala Compiler as dependencies, the testing introduces more (such as IO). This creates problem for new Scala versions where IO or test libraries do not exist yet (e.g. Scala 2.13.0-M2).
This also removes the Mima test due to the lack of 2.13 bridge for Zinc 1.0.0.
Compiler bridge just needs to compile itself against the interface and Scala compiler, so there's no need to run Mima test.
Dale Wijnand
Eugene Yokota
Ethan Atkins
Kazuhiro Sera
xuwei-k
Jason Pickens
Łukasz Wawrzyk
exoego
Johannes Rudolph