Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build failure with Scala 2.13.1 #295

Closed
plokhotnyuk opened this issue Sep 18, 2019 · 14 comments · Fixed by #300
Closed

Build failure with Scala 2.13.1 #295

plokhotnyuk opened this issue Sep 18, 2019 · 14 comments · Fixed by #300

Comments

@plokhotnyuk
Copy link

https://travis-ci.org/plokhotnyuk/expression-evaluator/jobs/586472890

error] ## Exception when compiling 1 sources to /Users/travis/build/plokhotnyuk/expression-evaluator/target/scala-2.13/classes
[error] java.lang.NoSuchMethodError: scala.tools.nsc.Global.reporter()Lscala/tools/nsc/reporters/Reporter;
[error] scoverage.ScoverageInstrumentationComponent$$anon$1.run(plugin.scala:119)
[error] scala.tools.nsc.Global$Run.compileUnitsInternal(Global.scala:1506)
[error] scala.tools.nsc.Global$Run.compileUnits(Global.scala:1490)
[error] scala.tools.nsc.Global$Run.compileSources(Global.scala:1482)
...

https://travis-ci.org/plokhotnyuk/jsoniter-scala/jobs/586468216

[error] ## Exception when compiling 4 sources to /Users/travis/build/plokhotnyuk/jsoniter-scala/jsoniter-scala-core/target/scala-2.13/classes
[error] java.lang.NoSuchMethodError: scala.tools.nsc.Global.reporter()Lscala/tools/nsc/reporters/Reporter;
[error] scoverage.ScoverageInstrumentationComponent$$anon$1.run(plugin.scala:119)
[error] scala.tools.nsc.Global$Run.compileUnitsInternal(Global.scala:1506)
[error] scala.tools.nsc.Global$Run.compileUnits(Global.scala:1490)
[error] scala.tools.nsc.Global$Run.compileSources(Global.scala:1482)
@ILLKO
Copy link

ILLKO commented Sep 18, 2019

Needs scalac-scoverage-plugin with this pull request merged scoverage/scalac-scoverage-plugin#279

@gslowikowski
Copy link
Member

This issue and scoverage/scalac-scoverage-plugin#279 are two different issues.

That one is with plugin test code. This one causes errors in runtime. The source of these two problems is the same - Scala compiler 2.13.1 is not backward compatible with 2.13.0. Scoverage plugin version compiled with Scala 2.13.0 does not work with Scala 2.13.1.

I don't know if this incompatibility is accidental and should be considered a bug or on purpose and what will next version of compiler (Global class) look like. Will they be compatible with version 2.13.0 or 2.13.1 or maybe not compatible with any of them.

@lrytz
Copy link

lrytz commented Sep 20, 2019

scoverage/scalac-scoverage-plugin#279 allows compiling the plugin against 2.13.1 (and it remains compileable with older Scala versions).

The runtime failure is because the scala-compiler.jar of 2.13.1 is not binary compatible with the scala-compiler.jar of 2.13.0. This is not a bug, we only guarantee binary compatibility for the library. This means that compiler plugins have to be fully cross-versioned.

Concretely, scalac-scoverage-plugin_2.13:1.4.1 should not exist, instead there should be scalac-scoverage-plugin_2.13.0 and scalac-scoverage-plugin_2.13.1.

Note that this is true for all compiler plugins (see typelevel/kind-projector#15 for example).

For reference, the changes to wartremover that were done by @xuwei-k to support full cross-versioning: wartremover/wartremover@5c59c86...acc56b8

JanBessai added a commit to combinators/templating that referenced this issue Sep 20, 2019
JanBessai added a commit to combinators/templating that referenced this issue Sep 20, 2019
JanBessai added a commit to combinators/templating that referenced this issue Sep 20, 2019
JanBessai added a commit to combinators/templating that referenced this issue Sep 20, 2019
JanBessai added a commit to combinators/templating that referenced this issue Sep 20, 2019
@Christewart
Copy link

Just a 👍 , i'm encourtering this failure when attempting to upgrade bitcoin-s to 2.13.1 https://travis-ci.org/bitcoin-s/bitcoin-s/jobs/588220140#L352

35VLG84 added a commit to e257-fi/dirsuite that referenced this issue Sep 28, 2019
Disable coverage until sbt-scoverage is fixed:
scoverage/sbt-scoverage#295

Signed-off-by: 35V LG84 <[email protected]>
mkroli added a commit to mkroli/dns4s that referenced this issue Oct 1, 2019
DieBauer added a commit to DieBauer/cats that referenced this issue Oct 2, 2019
@regis-leray
Copy link

I have the same issue with scala 2.13.1 and scoverage 1.6.0

openjdk 11.0.4 2019-07-16
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.4+11)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.4+11, mixed mode)

[error] java.lang.NoSuchMethodError: 'scala.tools.nsc.reporters.Reporter scala.tools.nsc.Global.reporter()'
[error] scoverage.ScoverageInstrumentationComponent$$anon$1.run(plugin.scala:119)
[error] scala.tools.nsc.Global$Run.compileUnitsInternal(Global.scala:1506)
[error] scala.tools.nsc.Global$Run.compileUnits(Global.scala:1490)
[error] scala.tools.nsc.Global$Run.compileSources(Global.scala:1482)
[error] scala.tools.nsc.Global$Run.compile(Global.scala:1614)
[error] xsbt.CachedCompiler0.run(CompilerInterface.scala:153)
[error] xsbt.CachedCompiler0.run(CompilerInterface.scala:125)
[error] xsbt.CompilerInterface.run(CompilerInterface.scala:39)
[error] java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[error] java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[error] java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[error] java.base/java.lang.reflect.Method.invoke(Method.java:566)

@nrinaudo
Copy link

nrinaudo commented Oct 9, 2019

I'm also struggling with this issue. If there anything I can do to help getting it resolved?

@leonardehrenfried
Copy link

I'm not a maintainer but I would guess that if you want to help, you can open a PR that adds full cross-compilation down to the minor version number, as suggested here: #295 (comment)

Basically, this plugin is only cross-compiled for scala 2.13 when it actually needs to be compiled for 2.13.0 and 2.13.1.

Usually this isn't a problem but there appears to be an API change between 2.13.0 and 2.13.1.

kailuowang pushed a commit to typelevel/cats that referenced this issue Oct 11, 2019
* Enable scoverage in 2.13 build

Beware of 2.13.1 issue regarding scoverage/sbt-scoverage#295

* Enable apidoc generation for 2.13

* travis: Enable codecoverage for jvm build

* Add flag to codecov to differentiate scala versions

* Remove sbt keys that do nothing
@nrinaudo
Copy link

nrinaudo commented Oct 14, 2019

There's another, quicker solution: the one that @olafurpg asked me to put together for mdoc in scalameta/mdoc#196.

Instead of changing the publication mechanism and publishing artifacts for every single version of Scala, keep publishing global ones for 2.11, 2.12 and 2.13, but only make them compatible with the latest Scala version.

For example, if we were to do that to scoverage, the next version would only be tested against 2.11.12, 2.12.10 and 2.13.1.

With the current state of Scala, that would mean:

  • compatible with 2.11.x for all x
  • compatible with 2.12.x for all x
  • compatible with 2.13.1, but not 2.13.0

If the reporter API stays stable from now on, problem sorted. If it doesn't, "just" fix the breakage and release a non-backwards compatible build for the latest versions.

I can absolutely have a go at that if you feel this would be an acceptable solution.

@leonardehrenfried
Copy link

Speaking as a user, this is a totally acceptable solution.

@nrinaudo
Copy link

I have a working proof of concept - it's really very little work.

Replace 2.13.0 by 2.13.1 in scalac-scoverage-plugin's build file, and publish locally (+publishLocal).
This should publish version 1.4.1-SNAPSHOT.

Load up whatever project you have that uses scoverage and 2.13.1, and set the appropriate property:

set every coverageScalacPluginVersion := "1.4.1-SNAPSHOT"

Done. You now have working code coverage.

The clean thing to do would be to publish scalac-scoverage-plugin 1.4.1, then update sbt-scoverage so that it defaults to 1.4.1 and not 1.4.0, and publish that. You're done. It's two 1-line-diffs, with the caveat that you've lost support for 2.13.0.

Happy to submit the corresponding PRs, but I'd love to get approval from a project maintainer first that this is the way they want to go.

@nrinaudo
Copy link

nrinaudo commented Oct 16, 2019

PRs submitted:

Do let me know if there's anything else I can do to push this forward!

rtyley added a commit to guardian/twitter4s that referenced this issue Oct 21, 2019
This project now compiles with Scala 2.13 by default, while still
cross-compiling to Scala 2.12 & 2.11.

Although Scala 2.13.1 has been released, this change sticks with 2.13.0,
as `scoverage` has not yet released an update compatible with 2.13.1:

scoverage/sbt-scoverage#295
scoverage/scalac-scoverage-plugin#283
scoverage/sbt-scoverage#299


Migration issues addressed with the update to Scala 2.13:

### Underscore (`_`) is no longer a valid identifer for `val`s

Using underscore like this is no longer allowed...

```
implicit val _ = ...
```

...we have to give the `val` a valid name (even if it's just `v`):


```
implicit val v = ...
```

See also:

* scala/bug#10384
* scala/bug#7691
* scala/scala#6218

### `Map.mapValues()` now returns a `MapView` rather than a `Map`

We usually want a `Map`, so we can just add in a `.toMap` to the end of
the expression - it's harmless in Scala 2.12, and allows the code to
compile in Scala 2.13. `Map.mapValues()` itself is deprecated in Scala
2.13, but using the new recommended alternative doesn't work in Scala 2.12.

https://docs.scala-lang.org/overviews/core/collections-migration-213.html#what-are-the-breaking-changes

See also:

* scala/bug#10919
* scala/scala#7014

### `.to` can no longer infer what resulting collection type you want

This is all part of `CanBuildFrom` going away in Scala 2.13:

https://www.scala-lang.org/blog/2018/06/13/scala-213-collections.html#life-without-canbuildfrom
rtyley added a commit to guardian/twitter4s that referenced this issue Oct 21, 2019
This project now compiles with Scala 2.13 by default, while still
cross-compiling to Scala 2.12 & 2.11.

Although Scala 2.13.1 has been released, this change sticks with 2.13.0,
as `scoverage` has not yet released an update compatible with 2.13.1:

scoverage/sbt-scoverage#295
scoverage/scalac-scoverage-plugin#283
scoverage/sbt-scoverage#299


Migration issues addressed with the update to Scala 2.13:

### Underscore (`_`) is no longer a valid identifer for `val`s

Using underscore like this is no longer allowed...

```
implicit val _ = ...
```

...we have to give the `val` a valid name (even if it's just `v`):


```
implicit val v = ...
```

See also:

* scala/bug#10384
* scala/bug#7691
* scala/scala#6218

### `Map.mapValues()` now returns a `MapView` rather than a `Map`

We usually want a `Map`, so we can just add in a `.toMap` to the end of
the expression - it's harmless in Scala 2.12, and allows the code to
compile in Scala 2.13. `Map.mapValues()` itself is deprecated in Scala
2.13, but using the new recommended alternative doesn't work in Scala 2.12.

https://docs.scala-lang.org/overviews/core/collections-migration-213.html#what-are-the-breaking-changes

See also:

* scala/bug#10919
* scala/scala#7014

### `.to` can no longer infer what resulting collection type you want

This is all part of `CanBuildFrom` going away in Scala 2.13:

https://www.scala-lang.org/blog/2018/06/13/scala-213-collections.html#life-without-canbuildfrom
francisdb added a commit to waylayio/kairosdb-scala that referenced this issue Nov 18, 2019
@polomarcus
Copy link

Just met this error, and finding this thread solved is beautiful

Merci @nrinaudo et @D-Roch 🏆

danny-goldberg-rally added a commit to danny-goldberg-rally/scalacheck-ops that referenced this issue Jan 26, 2021
danny-goldberg-rally added a commit to danny-goldberg-rally/scalacheck-ops that referenced this issue Jan 26, 2021
@asavelyev01
Copy link

Just met this error with Scala 2.12.13. Does it need a different fix?

@eugeniyk
Copy link

@asavelyev01 duplicate of #319

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.