**Problem**
We changed the content of Chrome tracing file incorrectly
and renamed tid to tname.
**Solution**
1. This renames tname back to to tid.
2. To retain the fix to avoid Thread#getId, this calls
either the JDK 8 way or the JDK 19 way reflectively.
Add a `allowUnsafeScalaLibUpgrade` setting (default is `false`) to
demote the SIP-51 build failure to a warning.
If the scalaVersion is 2.13.12 but some dependency pulls in
scala-library 2.13.13, the compiler will stay at 2.13.12, but
the dependency classpath will contain scala-library 2.13.13.
This usually works, the compiler can run fine with a newer
scala-library on its dependency classpath.
Macro expansion may fail, if the macro uses some library
class / method that doesn't exist in the old version.
The macro itself is loaded from the dependency classpath
into the class loader running the compiler, where the older
Scala library is on the runtime classpath.
Using the Scala REPL in sbt may also fail in a similar fashion.
**Problem**
BOM support current has perf issues.
**Solution**
This bumps Coursier to 2.1.22.
This also adds a new setting `csrMavenDependencyOverride`,
which will default to false.
**Problem**
sbt 1.10.0 added support for ++ command with external reference,
but broke ++ takes an aggregate command with slash.
**Solution**
This fixes the parser
**Problem**
Currently scripted does version checking to block sbt 2.x plugins
to be cross published from sbt 1.x.
**Solution**
Remove the sbt version matching.
The BSP server didn't reset old diagnostic messages sent to BSP clients under
certain circumstances. This commit mitigates this edge case and ensures that
diagnostics for files that previously had compilation problems are properly
reset when fresh diagnostics messages are sent.
The culprit was a mismatch of map keys: Files with problems were sometimes recorded
under an absolute path, but later attempted to be retrieved by virtual path.
This follows on from #7470, to include all sources, not just managed and
unmanaged, in the source jar, along with all resources (previously only
unmanaged resources were included).
This means that if, for whatever crazy reason, someone does modify the
`sources` task to include additional sources or filter out sources, rather than
using the managed or unmanaged source mechanisms, their changes will still be
reflected in the source jar.
See also https://github.com/sbt/zinc/pull/1326
This adds a new setting `enableConsistentCompileAnalysis`,
which enables the new "Consistent" Analysis format,
which is faster and more repeatable than the status quo.
This is initialized to `true` by default.
It can be opted out either by the setting or using
`-Dsbt.analysis2024=false`.
When a macro was compiled against a new scala-library (say 2.13.15),
the runtime classpath of the Scala compiler should not contain an older
scala-library. Otherwise the macro can cause a NoSuchMethodException
during expansion.
This commit updates scala-library in the scalaInstance to the version
on the projects dependency classpath.
The `csrSameVersions` setting can be used to keep dependencies at the
same version.
By default it's used for Scala artifacts. They need to be kept at the
same version because the compiler / reflect are built with
cross-artifact inlining enabled.
`csrSameVersions := Seq(Set(scala-library, scala-reflect, scala-compiler, scalap))`
Users can make use of the new setting in the following way:
- `csrSameVersions += Set[InclExclRule]("com.corp" % "lib", "com.corp" % "lub")`
- `csrSameVersions += Set[InclExclRule]("com.corp" % "lib-family-*")`
When expanding a macro compiled against a new Scala library, the
runtime classpath of the compiler should not contain an older library.
Otherwise a NoSuchMethodException can occur.
A similar issue is present when running the Scala repl through sbt.
An input line compiled against a new library could fail to run if
the repl's runtime classpath is on an old version.
There are a couple of settings / configs that affect this, summary
below. The change in this PR seems to be the most narrow.
`scalaModuleInfo.value.overrideScalaVersion` in sbt
- affects how sbt to sets coursier's `forceScalaVersion` (see below)
- used by librarymanagement.ivy. If true, add a OverrideScalaMediator
See sbt/sbt#2634. Probably not relevant when using coursier.
`autoScalaLibrary` setting in sbt
- automatically add `scala-library` (or `scala3-library`) as a project
dependency
- also used for `forceScalaVersion` (see below)
`CoursierConfiguration.autoScalaLibrary`
- if `true` then Coursier `ResolutionParams.forceScalaVersion` is set
to to `true`
- initialized by sbt to
`autoScalaLibrary.value &&
!ScalaArtifacts.isScala3(sv) &&
!Classpaths.isScala213(sv) && // added in this commit
scalaModuleInfo.forall(_.overrideScalaVersion)`
coursier `ResolutionParams.forceScalaVersion`
- if true, `scala-library` / `scala-reflect` / `scala-compiler` /
`scalap` are forced to the scala version, not actually resolved
- for Scala 3, the `scala3-library` and `scala3-compiler` versions
are forced
**Problem**
Plugins are topologically sorted, but plugins with equal weigh could
modify the same key via `~=` etc, resulting in different builds
depending on the artifact.
**Solution**
This attempts to fix that by first sorting the selected plugins
by the class name before sorting it topologically.
Problem
-------
Starting Scala 2.13.12, Scala 2 has in-sourced the compiler bridge
implementtion, which hopefully will be kept up to date more than the
ones in Zinc.
Solution
--------
This switches to using the pre-compiled compiler bridge for >=2.13.12.
In addition to ExecuteProgress, this new interface allows builds and plugins to receive events when commands start and finish, including the State before and after each command. It also makes cancellation visible to clients by making the Cancelled type top-level.
Fixes https://github.com/sbt/sbt/issues/7327
**Problem**
In builds with mixed Scala patch versions (like scalameta),
it's possible for a core subproject to be set to the lastest 2.12.x,
but the compiler plugin component is cross published to 2.12.0 etc.
`++ 2.12.0` in this case does not work since sbt 1.7.x onwards requires
the queried Scala version to be listed in `crossScalaVersions`.
**Solution**
This implements sbt 1.6.x-like fallback mechanism,
but instead of using the queried version (e.g. 2.12.0) it will set
the Scala version to one of listed versions that is binary compatible.
Dmitrii Naumenko
Josh Soref
Eugene Yokota
Lukas Rytz
Derek Wickern
friendseeker
adpi2
philippus
Seth Tisue
kenji yoshida
SlowBrainDude
James Roper
Tammo Steffens
Aleksandra Zdrojowa
unknown
Martin Duhem
MINKYU LEE
Matthias Kurz
Michel Davit
Matthew de Detrich
Iulian Dragos