Relative path for compiler plugin while using sbt >= 1.4.0 breaks compilation.

[ckipp01]

I've noticed that when using sbt >= 1.4.0 and sbt-bloop, there is a difference in how a compiler plugin is listed under project.scala.options in the bloop json file. We'll use wart remover as an example. When using sbt 1.3.13 and wart remover the path to the plugin is absolute and pointing towards my coursier cache. However, in sbt >= 1.4.0 it's a relative path to /target/compiler_plugins/<plugin>. For example using 1.3.13

"project": {
  "scala": {
    "options": [
      "-Xplugin:/Users/ckipp/Library/Caches/Coursier/v1/https/repo1.maven.org/maven2/org/wartremover/wartremover_2.13.3/2.4.13/wartremover_2.13.3-2.4.13.jar"
    ]
  }
}

Using >= 1.4.0

"project": {
  "scala": {
    "options": [
      "-Xplugin:target/compiler_plugins/wartremover_2.13.3-2.4.13.jar",
    ]
  }
}

This causes issues when compiling:

❯ bloop compile (bloop projects)
Compiling wart-remover-bloop (1 Scala source)
[E] [E-1] bad option: -P:wartremover:traverser:org.wartremover.warts.Var
[E] [E-1] bad option: -P:wartremover:traverser:org.wartremover.warts.TryPartial
[E] [E-1] bad option: -P:wartremover:traverser:org.wartremover.warts.TraversableOps
[E] [E-1] bad option: -P:wartremover:traverser:org.wartremover.warts.Throw
[E] [E-1] bad option: -P:wartremover:traverser:org.wartremover.warts.StringPlusAny
[E] [E-1] bad option: -P:wartremover:traverser:org.wartremover.warts.Serializable
[E] [E-1] bad option: -P:wartremover:traverser:org.wartremover.warts.Return
[E] [E-1] bad option: -P:wartremover:traverser:org.wartremover.warts.Product
[E] [E-1] bad option: -P:wartremover:traverser:org.wartremover.warts.OptionPartial
[E] [E-1] bad option: -P:wartremover:traverser:org.wartremover.warts.Null
[E] [E-1] bad option: -P:wartremover:traverser:org.wartremover.warts.NonUnitStatements
[E] [E-1] bad option: -P:wartremover:traverser:org.wartremover.warts.IsInstanceOf
[E] [E-1] bad option: -P:wartremover:traverser:org.wartremover.warts.EitherProjectionPartial
[E] [E-1] bad option: -P:wartremover:traverser:org.wartremover.warts.DefaultArguments
[E] [E-1] bad option: -P:wartremover:traverser:org.wartremover.warts.AsInstanceOf
[E] [E-1] bad option: -P:wartremover:traverser:org.wartremover.warts.Any
Compiled wart-remover-bloop (92ms)
[E] Failed to compile 'wart-remover-bloop-test','wart-remover-bloop'

If the path is changed to an absolute path pointing in the target directory, then there is no problem. I'm unsure if that path is given from sbt in this manner, if Bloop is in charge of getting it from sbt and making sure it's absolute, or even something else.

You can reproduce this by the following steps

• Run g8 scala/hello-world.g8
• Add in addSbtPlugin("org.wartremover" % "sbt-wartremover" % "2.4.13")
• Add in addSbtPlugin("ch.epfl.scala" % "sbt-bloop" % "1.4.5-8-6cc6911d")
• Run sbt bloopInstall
• Run bloop compile $(bloop projects)

[tgodzik]

Thanks for finding this! I will need to take a look at this soon.

[tgodzik]

Is this the reason for https://github.com/scalameta/metals/pull/2279 ?

[ckipp01]

Is this the reason for scalameta/metals#2279 ?

I don't believe so. I still don't know what's going on there. When I compare the json files for 1.4.2 and 1.4.3 all of the sbt source jars are missing. However, when I checked they were published, so I have no idea why as of 1.4.3 the sources aren't getting included.

[ckipp01]

So it looks like this may be wart remover specific. This commit is the one that seems to have caused it https://github.com/wartremover/wartremover/commit/fadeadc174a10874e301ca4d6161f0a1751fc330 since they needed to go away from the absolute path in relation to this https://github.com/sbt/sbt/issues/6027.

[tgodzik]

Is that relative path relative to the workspace? Maybe we could detect if a path is relative and try to do workspace.resolve(path) ?

[tgodzik]

We already do something similar here: https://github.com/scalacenter/bloop/blob/master/integrations/sbt-bloop/src/main/scala/bloop/integrations/sbt/SbtBloop.scala#L616

We could see if an option starts with -Xplugin: but doesn't follow with / and then try to use the working dir to find the absolute path.

[sjrd]

but doesn't follow with /

Because of Windows and its C:\ or C:/

[tgodzik]

but doesn't follow with /

Because of Windows and its C:\ or C:/

Right, thanks @sjrd ! As always I forgot about windows :sweat:

[pavelfatin]

Related: https://youtrack.jetbrains.com/issue/SCL-18534#focus=Comments-27-4614571.0-0