You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not sure how exactly this can be achieved, but it would be beneficial to emit a specialised warning for packages/definitions SN doesn't have on its own (NIR) classpath.
This should make the experience better for cross-compiling codebases.
Simple package check will likely not suffice, as we have shims like this shipped in separate libraries and likely will have more of those
The text was updated successfully, but these errors were encountered:
Good idea!
The only way how we could be sure that symbols exists would be to check if javalib for given Scala Native version contains them. Compiler plugin itself cannot have classpath dependenices (that's why the nir/util projects are embedded into the compiler plugin using extra source dependencies).
I think we can do it other way around - we can create an sbt/mill plugin that would inspect the generated NIR files for any symbols that are not defined after the compilation. It could use existing mechanism for checking NIR that we use after classloading in the SN toolchain.
I'm not sure how exactly this can be achieved, but it would be beneficial to emit a specialised warning for packages/definitions SN doesn't have on its own (NIR) classpath.
This should make the experience better for cross-compiling codebases.
Simple package check will likely not suffice, as we have shims like this shipped in separate libraries and likely will have more of those
The text was updated successfully, but these errors were encountered: