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

WIP: feature: Support NIR file decoding #5588

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

coreyoconnor
Copy link
Contributor

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:

image

path: AbsolutePath
): Future[DecoderResponse] = {
val scalaNativeCLIDependency =
Dependency.of("org.scala-native", "scala-native-cli_2.13", "0.4.10")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

coreyoconnor commented Aug 31, 2023 via email

@tgodzik
Copy link
Contributor

tgodzik commented Sep 1, 2023

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

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 this pull request may close these issues.

None yet

3 participants