Conflicts:
	project/Dependencies.scala

 Conflicts:
	project/build.sbt

 Conflicts:
	project/build.sbt

 Conflicts:
	integrations/sbt-bloop/src/main/scala/bloop/integrations/sbt/SbtBloop.scala

 Conflicts:
	docs-gen/src/main/scala/bloop/docs/ReleasesModifier.scala
	docs-gen/src/main/scala/bloop/docs/Sonatype.scala
	launcher-test/src/test/scala/bloop/launcher/LauncherBaseSuite.scala

 Conflicts:
	project/Dependencies.scala
	project/build.sbt

 Conflicts:
	project/Dependencies.scala

 Conflicts:
	project/build.sbt

 Conflicts:
	.github/workflows/ci.yml

 Conflicts:
	project/Dependencies.scala
	project/build.sbt

 Conflicts:
	project/Dependencies.scala

Merge upstream changes

Didn't try to run them locally…

Seems this fixed some tests locally…

Many test fixtures need to be tweaked for 2.13.

Not sure why this wasn't a problem with the sbt build…

Add Mill build

Not sure why, it fails on the CI with
```
shared[2.12.17].docJar java.lang.reflect.InvocationTargetException
    java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
    java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    java.base/java.lang.reflect.Method.invoke(Method.java:568)
    mill.scalalib.worker.ZincWorkerImpl.$anonfun$docJar$1(ZincWorkerImpl.scala:124)
    mill.scalalib.worker.ZincWorkerImpl.$anonfun$docJar$1$adapted(ZincWorkerImpl.scala:104)
    mill.api.FixSizedCache.withCachedValue(FixSizedCache.scala:66)
    mill.scalalib.worker.ZincWorkerImpl.withCompilers(ZincWorkerImpl.scala:421)
    mill.scalalib.worker.ZincWorkerImpl.docJar(ZincWorkerImpl.scala:104)
    mill.scalalib.ScalaModule.packageWithZinc$1(ScalaModule.scala:247)
    mill.scalalib.ScalaModule.$anonfun$docJar$2(ScalaModule.scala:342)
    mill.define.Task$TraverseCtx.evaluate(Task.scala:380)
java.lang.AssertionError: assertion failed:
  No RuntimeVisibleAnnotations in classfile with ScalaSignature attribute: package object coursier
     while compiling: /home/runner/work/bloop-core/bloop-core/shared/src/main/java/bloop/io/internal/ProjDirHelper.java
        during phase: globalPhase=typer, enteringPhase=parser
     library version: version 2.12.17
    compiler version: version 2.12.17
```

Add bloop-cli modules

 Conflicts:
	project/Dependencies.scala

 Conflicts:
	.scalafmt.conf

Add last Scala CLI repo updates

Merge upstream changes

Bumps [coursier/setup-action](https://github.com/coursier/setup-action) from 1.2.0 to 1.3.0.
- [Release notes](https://github.com/coursier/setup-action/releases)
- [Commits](coursier/setup-action@v1.2...v1.3.0)

---
updated-dependencies:
- dependency-name: coursier/setup-action
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

Previously, if importing build as Bloop we would not get proper classpath for bridge modules as they would be missing tansitive classes directories. This is probably a bug in mill bloop plugin, but I am not sure we want to dig in there currently. Now, I added explicit depndency on those moduls which seems to have fixed compilation.

chore: Adjust Mill build file to fix Bloop compilation

It seems that the genericClassesDir is not being used at all by the compiler, so cleaning orphan directories in it was not achieving anything.

We might need to figure out how to use `genericClassesDir` and whether it needs to be used at all, but for now this fixes the issue of large .bloop directory.

Fixes scalacenter#2056

Previously, when hashing would fail the whole compilation would also fail and while this seems incredibly rare let's try to guard ourselves here.

Connected to scalacenter#2053

This makes a few changes:

- gets rid of the external organizeImports rule which is now inlined
- removes logic that checks for 2.11 (we no longer support it)
- ensures scalafixSettings is enabled for buildpress

For projects that use javac processorpath option append semanticdb
plugin path to avoid compilation errors

updats sbt to 1.7.2 to match all other projects

removes unnecessary appending "/" before path

Co-authored-by: Tomasz Godzik <tgodzik@users.noreply.github.com>

use project path instead of workspace path to assert semanticdb options

Previously, we would use a commited semanticdb jar for tests in frontend, however this caused two issues:

- semanticdb would be always out of date
- scala version updates would require also bumping semanticdb manually and fetching the jar

Now, we use the latest semanticdb plugin always, which should work properly.

…vant

Previously, if python was not available on PATH we would fail the tests. Now, we check both python and python 3 executables first, if none of them exists then we ignore the tests. This will pop up on CI if source generators are broken.

set scala-java-processorpath project version to "2.12.18"

Should help with scalacenter#2053

The binary is described as:
```
A binary entry represents either the jar or the
concrete class file from which the Scala compiler
knows that <code>onBinaryClassName</code> comes from.
```

Previously, we wouldn't produce semanticdb files for older version of Scala since we wouldn't find the correct artifact if we stopped publishing for a particular version.

Now, we try and find the latest version that still supported that Scala version.

This is similar to the change we did in Metals in regards to the presentation compiler interface, where we would fetch old mtags for unsupported scala version and this way always support a particular version.