on Scala 2.11, version 1.1.2 may run afoul of sbt classpath issue

[Philippus]

Philippus/bump#8 fails with the following exception in scala 2.11:

SemVer.nextStable removes pre-release information if available: Exception raised on property evaluation.
[info] > Exception: java.lang.AbstractMethodError: nl.gn0s1s.bump.SemVerParser$.scala$util$parsing$combinator$Parsers$$lastNoSuccessVar()Lscala/util/DynamicVariable;

Looks like #108 after testing locally.

Scala 2.12 and 2.13.0-RC1 are ok.

[SethTisue]

the root cause is that the Scala 2.11 compiler itself has a dependency on scala-parser-combinators. that dependency was removed in 2.12.

the problem goes away if you set fork in Test := true, because then the compiler and its dependencies aren't on the classpath

previously here in this repo: #13

and, we went through this before with scala-xml at scala/scala-xml#195 /cc @ashawley

[SethTisue]

@eed3si9n why is this still happening even after sbt/zinc#505 ? the bump repo is on sbt 1.2.8, which includes the fix

[SethTisue]

the Shapeless repo only uses scala-parser-combinators in some example code, so this won't flow downstream to Shapeless users /cc @milessabin

specs2 has a scala-parser-combinators dependency, but fwiw it looks like it's only used by certain matcher types /cc @etorreborre

[SethTisue]

if a project has trouble it can always set fork ... (on 2.11 only, or build-wide). or add 1.1.1 or 1.1.2 to the classpath depending on whether they're on 2.13 or not, there are scenarios in which that wouldn't be okay. such scenarios are probably rare? but it does seem a bit dodgy

anyway, it seems like we should back-publish 1.1.1 for 2.13.0-RC1 so people will be less likely to be bitten. the underlying cause affects all scala-parser-combinators versions that aren't 1.04 (the version the 2.11 compiler uses), but the lastNoSuccessVar change in 1.1.2 seems to have made actual ensuing breakage much likelier

[xerial]

I hit this issue and switching 1.1.1 or 1.1.2 or using fork in True can be tricky.

[SethTisue]

I hit this issue and switching 1.1.1 or 1.1.2 or using fork in True can be tricky.

Yeah. Perhaps people landing on this ticket would like to leave links with sample diffs from their projects, to help others do likewise.

Also, this is obvious once you've understood the issue, but it's probably worth stating plainly:

Unless you fork, or until we have an sbt release with a fix, your tests aren't testing what they're supposed to be testing. They're testing something else. This was true already on 1.1.1 and previous versions too. It didn't start with the release of 1.1.2.

[xerial]

@SethTisue That's true.

Although it might have some overhead, adding fork in Test := True is most reliable to isolate libraries used in sbt and target applications.

[eed3si9n]

@SethTisue It's an sbt bug.

So basically sbt/zinc#505 fixed the bug for run

   def makeLoader(classpath: Seq[File], instance: ScalaInstance): ClassLoader =
-    filterByClasspath(classpath, makeLoader(classpath, instance.loader, instance))
+    filterByClasspath(classpath, makeLoader(classpath, instance.loaderLibraryOnly, instance))

but didn't for test it seems.

https://github.com/sbt/sbt/blob/v1.2.8/testing/src/main/scala/sbt/TestFramework.scala#L258

    val dual = new DualLoader(
      scalaInstance.loader,

I opened sbt/sbt#4609.

[SethTisue]

(closing the ticket since the bug isn't in this repo. still good we have this ticket to help searchers)

[OlegYch]

so, is 1.1.2 compatible with 1.0.4 or not? is 1.1.1 compatible with 1.0.4?

[OlegYch]

ok, i did some tests and see that while technically a lib compiled against 1.0.4 (play_2.11-2.5.18) still references a method which is no longer available it seems to never be called

private DynamicVariable scala$util$parsing$combinator$Parsers$$lastNoSuccessVar$lzycompute() { synchronized (this) { if (!this.bitmap$0) { this.scala$util$parsing$combinator$Parsers$$lastNoSuccessVar = Parsers.class.scala$util$parsing$combinator$Parsers$$lastNoSuccessVar(this); this.bitmap$0 = true; } return this.scala$util$parsing$combinator$Parsers$$lastNoSuccessVar; }  } 
public DynamicVariable<Option<Parsers.NoSuccess>> scala$util$parsing$combinator$Parsers$$lastNoSuccessVar() { return this.bitmap$0 ? this.scala$util$parsing$combinator$Parsers$$lastNoSuccessVar : scala$util$parsing$combinator$Parsers$$lastNoSuccessVar$lzycompute(); } 

[OlegYch]

then again, i'm not sure why would not-forking cause a problem...

[SethTisue]

i'm not sure why would not-forking cause a problem.

because #197 (comment)

[OlegYch]

@SethTisue so if i have a dependency like scala-compiler had i will have a problem too? i have a lib compiled again 1.0.4, should i expect it to fail running against 1.1.2?

[SethTisue]

I'm sorry, I don't know. I haven't followed the status of the different branches that closely, where and when MiMa was enabled, and so on.