Now with scala 2.13.3 being out I am having some issues with my build around the semanticdb versions. Is it possible to both update the handling for scala 2.13.3 and allow for separate configuration of the semanticdb-scalac version.

com.goyeau::mill-scalafix:8cfaccf not working

did you publish to maven repository

I believe this is actually related to #7, but I just came across this when trying to use ExplicitResultTypes on a project in 2.13.3. Currently you get an error like this:

[E0] The ExplicitResultTypes rule needs to run with the same Scala binary version as the one used to compile target sources (2.13). To fix this problem, either remove ExplicitResultTypes from .scalafix.conf or make sure the scalafixScalaBinaryVersion setting key matches 2.13.

The error is pretty specific to sbt, since it references a setting key, but would it be possible to add something like this so if someone hits on this they are able to just provide the scalafixScalaBinaryVersion in this scenario?

Also, super glad to see a scalafix mill integration 👍

I discovered this issue here: com-lihaoyi/mill#2922

And added a reproducer in form of an integration test in this PR: #172

Now that 0.11.0 is released it'd be great to get this published for 0.11 to unblock other plugins.

I am trying to use the latest mill-scalafix release v0.2.7 but I can't find it in https://mvnrepository.com/artifact/com.goyeau/mill-scalafix

I have some code with valid fewerBraces syntax but the scalafix plugin reports an error:

20: val helloWorker: URLayer[ZWorkerFactory, Unit] = ZLayer.fromZIO:
21:   ZIO.serviceWithZIO[ZWorkerFactory]: workerFactory =>
22:     for
23:       _      <- ZIO.logInfo("Started sample-worker")
24:       worker <- workerFactory.newWorker("sample-worker")
25:       _       = worker.addWorkflow[EchoWorkflow].from(new EchoWorkflowImpl)
26:     yield ()
27: 

The return from ./mill __.fix:

Rewriting and linting 4 Scala sources against 5 rules
/Users/cdepaula/repos/scala-playground/zio-temporal-hello/hello/src/Worker.scala:21:37: error: ; expected but : found
  ZIO.serviceWithZIO[ZWorkerFactory]: workerFactory =>
                                    ^
1 targets failed
hello.fix A source file failed to be parsed

After #102 mill-scalafix doesn't need to define a version of semanticdb.
The current latest version doesn't support Scala 2.13.9
A new release should fix this.

Could you publish a new version because the version of semanticdb used by the release 0.2.5 is not available in 2.13.7. I've seen that Scala-Stewart updated the dependency to .31 which should be fine for scala 2.13.7

Thanks

I was hoping to use some scalafix options to skip fixing of unchanged files compared to a main branch (to speedup CI).

I am not seeing a speedup, or even a difference in logging, when using the --diff-base option.

The following snippets are run inside this repo, on latest main.

--check works as expected (actually... I'm not so sure! Technically --check "Won't write to files." - which contradicts the output here!).

./mill all "__.fix --check"
[1/1] all > [47/47] mill-scalafix[0.10.7].fix
Rewriting and linting 3 Scala sources against 4 rules

with --check, --diff-base doesn't have impact:

❯ ./mill all "__.fix --check --diff-base main"
[1/1] all > [47/47] mill-scalafix[0.10.7].fix 
Rewriting and linting 3 Scala sources against 4 rules

even just --diff-base on its own seems to have no impact:

❯ ./mill all "__.fix --diff-base main"
[1/1] all > [47/47] mill-scalafix[0.10.7].fix 
Rewriting and linting 3 Scala sources against 4 rules

When running this on main (or a branch off main, with no some or no changes), it gives the same output.

The output I am expecting: No log line, when --diff-base main is used.

Similarly, using --files /absolute/path/to/ScalafixModule.scala still results logs about checking 3 Scala sources. I didn't successfully validate if more than 1 file is changed. I tried, by breaking a few rules in e.g. ScalafixModule, but they failed even with the rules commented out in .scalafix.conf.

It looks like running sbt "scalafixAll --check" (stolen from scalafix'sGitHub Action CI script) and sbt "scalafixAll --check --diff-base main" in the scalafix repo give similar results with no obserable speedup, so I can open a ticket there and link to this one.

A fix could be to parse (some of) the args and use that in the filesToFix method, but it's probably better done in scalafix. I didn't think too closely about it yet.

I think some arg parsing of e.g. --check would be necessary to give more accurate logs - e.g. [CHECK] Would rewrite and lint 3 Scala sources against 4 rules

The scalafix instantiation above is very costly in terms of IO, but above all CPU as it effectively classloads Scalafix together with the entire scala standard library (with a cold JIT cache), even if scalafixScalaBinaryVersion matches Mill's scala binary version.

I believe adding a Mill worker to hold this instance would greatly benefit to the perceived performance of scalafix on projects with multiple modules or for users calling scalafix repeatedly. sbt-scalafix does something similar almost from day one, and a while ago this regressed, causing a ~10x invocation runtime regression on builds with many modules.

When publishing a library using mill-scalafix, the final artifacts end up having semanticdb files in them.

import $ivy.`com.goyeau::mill-scalafix:0.2.2`
import coursier.Repository
import coursier.maven.MavenRepository
import mill._
import mill.define.Command
import mill.main.MainModule
import com.goyeau.mill.scalafix.ScalafixModule
import mill.scalalib._
import mill.scalalib.publish.{ Developer, PomSettings, VersionControl }
import os.Path
import versions.scalatest_embedded_kafka_version
import scala.io.Source
val mainModule: MainModule = this

trait Base extends ScalaModule with ScalafixModule {
  override def forkArgs =
    Seq("-Xmx4g", "-Xss100m")
  def scalaVersion = "2.12.11"

  def scalafixIvyDeps =
    Agg(ivy"com.github.liancheng::organize-imports:0.4.0", ivy"com.timushev::zio-magic-comments:0.1.0")

  override def scalacPluginIvyDeps = Agg(
    ivy"org.scalamacros:::paradise:2.1.1",
    ivy"org.wartremover:::wartremover:2.4.10"
  )
  override def compileIvyDeps = Agg(
    ivy"org.scalamacros:::paradise:2.1.1",
    ivy"com.github.ghik:::silencer-plugin:1.7.1",
    ivy"org.wartremover:::wartremover:2.4.10",
    ivy"org.projectlombok:lombok:${lombok_version}"
  )
  val safetyCompilerOptions = Set(
    "-P:wartremover:traverser:org.wartremover.warts.NonUnitStatements",
    //    "-Xfatal-warnings",
    "-Xlint:unused",
    "-deprecation",
    "-feature"
  )
  override def scalacOptions = super.scalacOptions() ++ safetyCompilerOptions

}
object myModule extends Base 

running any scalafix:

mill __.fix --rules OrganizeImports

getting error:

[29/130] myModule.compile 
[info] compiling 85 Scala sources and 5 Java sources to ....
[info] done compiling
Rewriting and linting 90 Scala sources against 1 rules
[34/130] matcher_core.fix 
Rewriting and linting 90 Scala sources against 1 rules
error: SemanticDB not found: myModule/src/org/MyClass.scala
1 targets failed
matcher_core.fix A semantic rewrite was run on a source file that has no associated META-INF/semanticdb/.../*.semanticdb

mill --version
Mill Build Tool version 0.9.6
Java version: 11.0.2, vendor: Oracle Corporation, runtime: /Library/Java/JavaVirtualMachines/openjdk-11.0.2.jdk/Contents/Home
Default locale: en_US, platform encoding: UTF-8
OS name: "Mac OS X", version: 10.16, arch: x86_64

It appears mill-scalafix 0.2.2 does not yet support Scala 3. At least, as soon as I change the scalaVersion to 3, I get

Resolution failed for 1 modules:
--------------------------------------------
  org.scalameta:semanticdb-scalac_3.0.0:4.4.10

when running mill on my project. Commenting out mill-scalafix makes the issue disappear.

Error message:

Failed to resolve ivy dependencies:Error downloading com.goyeau:mill-scalafix_2.13:0.2.7
  not found: ~/.ivy2/local/com.goyeau/mill-scalafix_2.13/0.2.7/ivys/ivy.xml
  not found: https://repo1.maven.org/maven2/com/goyeau/mill-scalafix_2.13/0.2.7/mill-scalafix_2.13-0.2.7.pom