Metals 1.4 fails compilation with Wartremover installed

[andyczerwonka]

Compiler quits with Wartremover Enabled

During today's upgrade from 1.3.5 to 1.4.0, I noticed that compilation of our projects just stopped compiling after a couple of projects. After looking at the bloop errors, I decided to remove WartRemover from our environment to see if that was cousing the issue. Once removed, Metals started working again.

I removed the following:

addSbtPlugin("org.wartremover" % "sbt-wartremover" % "3.2.3")

ThisBuild / wartremoverErrors ++= Seq(
  Wart.ArrayEquals,
  Wart.Recursion
)

ThisBuild / wartremoverExcluded += baseDirectory.value / "code" / "orion" / "ml-config-core" / "src" / "main" / "scala" / "db"

I've included the errors we were seeing.
reports.zip

Here are another set of errors after removing wartremover, but Metals does seem to work.

reports_removed_wartremover.zip

Expected behavior

I expect Metals to be tolerant of Wartremover, and continue to compile all of the code.

Operating system

Linux

Editor/Extension

VS Code

Version of Metals

v1.4.0

Extra context or search terms

wartremover

[andyczerwonka]

It looks to be the same problem as scalacenter/bloop#1421 and is a blocker for upgrading for us. We'll revert to 1.3.5 until such time that we have a solution.

[andyczerwonka]

Also looks like there's a solution coming. scalacenter/bloop#2485

[agilesteel]

We ran into the same issue. There is an even smaller reproduction (hello world essentially) that I reported on discord. I'll paste it here. Maybe someone will find it useful:

build.sbt

scalaVersion := "2.13.15"
wartremoverWarnings := Warts.all

project/plugins.sbt

addSbtPlugin("org.wartremover" % "sbt-wartremover" % "3.2.3")

src/main/scala/Main.scala

object Main extends App

[tgodzik]

Thanks! I think I already have a fix. As soon as it's merged I will release bloop, then probably metals also

[andyczerwonka]

@tgodzik can we close this as part of scalacenter/bloop#2485, or just waiting on a release?

[tgodzik]

I wanted to fix one thing before the release, should be this week. I will close this issue with the update of default Bloop version

[andyczerwonka]

I wanted to fix one thing before the release, should be this week. I will close this issue with the update of default Bloop version

@tgodzik Just curious if this fix is coming shortly?

[tgodzik]

I will release bloop tomorrow and you can check it out first.

[agilesteel]

I think 2.0.4 has issues. It doesn't even start. See how there is no output for 2.0.4 but there is for 2.0.3?

Another thing: the screenshot above was taken in Ubuntu (WSL actually). Bloop is available on arm since 2.0 but coursier doesn't want to launch it so cs launch bloop:1.6.0 -- about works but cs launch bloop:2.0.3 -- about doesn't. The screenshot below is from an m2 mac.

[tgodzik]

I am doing 2.0.5 release to fix things, but not sure about the second issue. Does it work if you do cs install bloop:2.0.3 ? Or cs launch ch.epfl.scala:bloop-cli_2.12:2.0.3 ?

[agilesteel]

Actually that second issue disappeared so nevermind. Also I just tested with 2.0.5 and at least it starts 🎉

[tgodzik]

The update to Bloop 2.0.5 was merged. If testing the nightly, you need to reimport the build for it to effect things. I will do a release next week.

[andyczerwonka]

We still don't have a 1.4.1 Metals release, so not sure this should be marked done? I realize it's a bloop issue, but Metals is specific about what version of bloop. I realize we can override, but users won't know to do that when they encounter the issue.

[agilesteel]

I agree. For what it's worth I confirm that it works with the pre-release 1.4.1. The bloop version needs to be explicitly set to 2.0.5 in the settings though. Merely using the 2.0.5 bloop CLI is not enough. The project needs to be generated with 2.0.5. Can't wait for the proper release...

[ritschwumm]

just tried with metals 1.4.1 and the only way to actually get rid of the errors was nuking all .metals and .bloop directories in the project - none of the build commands in metals made the error go away before. is this behaviour expected?

[tgodzik]

Did you reimport the build? You can always try to run with a verbose compilation and see if that shows what parameters are exactly used to compile.

[ritschwumm]

i restarted bloop as requested by metals,

i imported the build, i did a clean compile, i tried "clean and restart build server" "restart build server".

then i stopped code, killed bloop in the terminal and restarted code, then tried all of the above again.

after that i did the nuking and imported the build again for good measure, and everything was fine.

of course it may have been the doctor lying to me :)

[agilesteel]

Wait am I the only who nukes those folders on a daily bases? 🙈

[tgodzik]

The should not be necessary, but reset workspace will do that for you. If that doesn't help would be cool to get some information about what is going wrong.

[agilesteel]

Oh is that a new button? I'll try and report back...

[tgodzik]

This one

[ritschwumm]

@tgodzik makes me wonder - if "clean and restart build server" nukes the .bloop and .metals folders, then why would me doing that manually make any difference? i'll check if it see the same behaviour on one of my other projects.

edit
classical case of PEBKAC: nuking the directories is different in that it removes the bloop error reports, and i mostly looked into those to see whether anything is wrong. so only when they disappeared i started assuming everything is fine.

[tgodzik]

It doesn't fully remove .bloop and .metals, only the Bloop artifacts, everything else should not cause any issues. It's just Metals indexes and some information about when was the project last imported etc. And also bloop json files, which should be correct also