WIP: feature: Support NIR file decoding

[coreyoconnor]

Adds support for decoding NIR files using scala-native-cli tooling.

WIP:

• how to select the class from the native target? This selects the preferred target (?) then replaces ".java" with ".nir". Which does not work in general.
• tests?

NIR decoded, with minor changes to emacs lsp-metals, looks like:

[armanbilge]

Latest is 0.4.14. This will have to stay pretty up-to-date b/c NIR is continually evolving, I wonder if there is a better way we can manage this version.

[coreyoconnor]

I guess my concern was having metals depend on the scala-native-cli (or nir) libraries directly. If that's not a concern then this dynamic download is probably not required.

[armanbilge]

Ah, actually I think a dynamic download is better because it would allow the scala-native-cli version to be bumped to latest without requiring a new release of metals.

[coreyoconnor]

I'm curious if I can:

1. add this as an optional dep so steward can do the update PRs.
2. Pass the version in with build info
3. Default a config to that version
4. Use that condid here

A few steps but would hopefully balance devex of this code with usability

[tgodzik]

Could we not check the classpath which version of native is being used?

[coreyoconnor]

I would think so? If there is a way to access the native build target then I presume that can be inspected to determine the native version.

[tgodzik]

We don't have a separate build target data for native (could be done), but we do have a list of jars that is being used, so potentially we could scan it for a particular native jar and check the pom.xml or try to figure out native version from the name (not the greatest, but we can fallback to the newest known version if the approach fails)

[coreyoconnor]

I am interested in what would be required to add build target data for native.Any pointers on where to start? That said, starting with some heuristics would be nice to get going - and give some future fallbacks. So I'll start with figuring out from name - but hopefully well abstracted.

…

-Corey O'Connor ***@***.***

On Thu, Aug 31, 2023 at 2:16 AM Tomasz Godzik ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In metals/src/main/scala/scala/meta/internal/metals/FileDecoderProvider.scala <#5588 (comment)>: > @@ -568,6 +574,57 @@ final class FileDecoderProvider( } } + private def decodeNIR( + path: AbsolutePath + ): Future[DecoderResponse] = { + val scalaNativeCLIDependency = + Dependency.of("org.scala-native", "scala-native-cli_2.13", "0.4.10") We don't have a separate build target data for native (could be done), but we do have a list of jars that is being used, so potentially we could scan it for a particular native jar and check the pom.xml or try to figure out native version from the name (not the greatest, but we can fallback to the newest known version if the approach fails) — Reply to this email directly, view it on GitHub <#5588 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAIMDNOSKNJNN6MOGPRZ3TXYBI5FANCNFSM6AAAAAA37FLIAE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[tgodzik]

I am interested in what would be required to add build target data for native.Any pointers on where to start?

We would need to modify or add platfrom data somewhere around https://github.com/build-server-protocol/build-server-protocol/blob/master/bsp4j/src/main/java/ch/epfl/scala/bsp4j/ScalaPlatform.java or https://github.com/build-server-protocol/build-server-protocol/blob/master/bsp4j/src/main/java/ch/epfl/scala/bsp4j/ScalaBuildTarget.java

We currently only have an enum only.

Later we would need to implement this in build server, we could start from Bloop

[tgodzik]

Let's close it for now and we can reopen once someone is able to work on it