Skip to content

Adding scalajs-linker as a dependency introduces unexpected error #21560

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

Closed
kincsescsaba opened this issue Sep 6, 2024 · 4 comments
Closed

Comments

@kincsescsaba
Copy link

kincsescsaba commented Sep 6, 2024

I ran the Scala 3 compiler (version: 3.5.0) successfully with the -scalajs option, sjsir files appear in the target directory as expected.

After this step, I wanted to create human-readable JavaScript. Therefore I added scalajs-linker as a dependency to the SBT project.

Running the first step again with the scalajs-linker being added, I unexpectedly get an error:

     while compiling: (inline)
        during phase: genSJSIR
                mode: Mode(ImplicitsEnabled)
     library version: version 2.13.14
    compiler version: version 3.5.0
            settings: -classpath "" -d (memory) -nowarn true -scalajs true -usejavacp true

An exception or error caused a run to abort: 'org.scalajs.ir.Types$ClassType org.scalajs.ir.Types$ClassType$.unapply(org.scalajs.ir.Types$ClassType)' 
java.lang.NoSuchMethodError: 'org.scalajs.ir.Types$ClassType org.scalajs.ir.Types$ClassType$.unapply(org.scalajs.ir.Types$ClassType)'
...

I assume the source to be compiled was OK, as sjsir files were generated.

Dependencies were set up with cross-version settings in SBT:

libraryDependencies ++= Seq(
      "org.scala-lang" %% "scala3-compiler" % scalaVersion.value,
      ("org.scala-js" %% "scalajs-library" % "1.16.0").withCrossVersion(CrossVersion.for3Use2_13),
      ("org.scala-js" %% "scalajs-linker" % "1.16.0").withCrossVersion(CrossVersion.for3Use2_13),
       ...
    )

The scalajs-library dependency did not introduce binary compatibility issues (Scala 2.13 and 3 should be binary compatible https://docs.scala-lang.org/overviews/core/binary-compatibility-of-scala-releases.html) while the linker (or an IR related dependency of it) did.

Looks like a nested case does not get an unapply method generated when it was compiled, this may cause the linker jar file to be binary incompatible, if there is no other circumstance that could cause this error.

@kincsescsaba kincsescsaba added itype:bug itype:crash stat:needs triage Every issue needs to have an "area" and "itype" label labels Sep 6, 2024
@sjrd
Copy link
Member

sjrd commented Sep 6, 2024

I believe you're mixing two unrelated things. One does not add the linker to a project to produce JavaScript. Instead we add the sbt-scalajs plugin as an sbt plugin, then add enablePlugins(ScalaJSPlugin) to the project that should be a JS project. In fact we don't even manually add -scalajs. The sbt plugin takes care of that. The linker must not appear in the dependencies of your project.

I suggest you follow a Scala.js tutorial or template project for the correct setup.

@kincsescsaba
Copy link
Author

kincsescsaba commented Sep 7, 2024

Thanks for looking into this.

I use a customized approach extending dotty.tools.dotc.Driver as I need on-the-fly arbitrary binary and JS generation. The mentioned standard solution, which I know of, seems to be for a fixed, non-changing codebase, which shall be in a JS project, as you have mentioned, so it's not the right fit for what I need.

I assumed the codebase to be self-documenting, and what can be found suggested to go in that direction.
The idea of the needed JS generation approach is not new, as can be seen here: https://stackoverflow.com/questions/40860950/build-js-from-sjsir-manually, unfortunately, this is for an outdated API.

If the plugin works with the latest versions, respectively 3.5.0 for Scala compiler and 1.16.0 for ScalaJs, then I could find the needed parts in plugin internals.

I'll check and revert if there is more information to see the reasons for this crash.

@sjrd
Copy link
Member

sjrd commented Sep 7, 2024

OK, then it's because you mix two incompatible versions of the scalajs-ir artifact's contents: one through the linker and one through the compiler. Either downgrade scalajs-linker to the same version that was used to build the compiler you're using. Or isolate the linker from the compiler by putting them on separate projects/classpaths.

Note the scalajs-ir artifact can break binary compatibility between minor releases, according to our versioning policy:
https://github.com/scala-js/scala-js/blob/v1.16.0/VERSIONING.md

@kincsescsaba
Copy link
Author

I'll do that. After further examining this issue, I found that we're not dealing with a missing unapply method but one generated with a different return type which I'll need to check if it is a bug or not. I'll check the details, as that could be a more general problem while closing this ticket and opening a new one if needed, as we've discussed the parts that were related to the ScalaJs-related side of this.

@sjrd sjrd closed this as not planned Won't fix, can't repro, duplicate, stale Sep 7, 2024
@sjrd sjrd added itype:question and removed itype:bug itype:crash stat:needs triage Every issue needs to have an "area" and "itype" label labels Sep 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants