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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

navigate to decompiled class if no source #3411

Closed
wants to merge 1 commit into from

Conversation

Arthurm1
Copy link
Contributor

Initial stab at scalameta/metals-feature-requests#210

I've no idea whether this is done in the correct area of code but it works so 馃し. If it is the correct area then I'll follow up with some tests.

One thing I've noticed is that scala.meta.internal.mtags.SymbolDefinition (and a number of other classes used for passing file locations around) use AbsolutePath to refer to file locations. This is handy because nio.Path validates that the format is correct and there are lots of useful Path methods but it's not so handy when all that's really going on is URIs are being passed around.

Downsides of using AbsolutePath are that any jar:file///somejar.jar!/someclass.java style reference has to be opened in java FileSystems#newFileSystem, even if you're not accessing it, or it throws an exception. Also - you can't use a virtual URI e.g. metalsDecode:jar:file:///somejar.jar!/someclass.class.cfr in AbsolutePath because it wraps nio.Path and I've not implemented a metalsDecode filesystem as I think that's over the top.

Is there a reason for using AbsolutePath rather than URI in all these places - or is it just historical?

@tgodzik
Copy link
Contributor

tgodzik commented Dec 28, 2021

I think it was useful to have Absolute Path as it has more utility methods and also probably some validation. That might not be 100 percent needed in all places.

Copy link
Contributor

@tgodzik tgodzik left a comment

Choose a reason for hiding this comment

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

Finally managed to take a look! I think it would be good to test it with some of the scalameta symbols that are generate from protobuf schema such as SymbolInformation

.map(f => {
val uri = f.jar.toURI.toString()
val fullURI =
URI.create(s"jar:${uri}!/${symbol.stripSuffix("#")}.class")
Copy link
Contributor

Choose a reason for hiding this comment

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

This might not work for some more complex Scala symbols such as inner classes 馃

In that case we might want to use ClasspathSymbols and find the class that contains the symbol.

.map(jarPath => List("--extraclasspath", jarPath.toString))
.getOrElse(List.empty)
val args = extraClassPath ::: List(
"--analyseas",
Copy link
Contributor

Choose a reason for hiding this comment

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

Typo?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No - although it does look it. The options is meant to mean ANALYSE_AS. Either jar or class

@doofin
Copy link
Contributor

doofin commented Jan 22, 2022

Thanks for this nice feature! Does it also works for scala js?

@Arthurm1
Copy link
Contributor Author

@doofin I haven't used scala js. Can you give an example of what you mean?

@tgodzik
Copy link
Contributor

tgodzik commented Jun 3, 2022

This is being done together with #3750, so closing

@tgodzik tgodzik closed this Jun 3, 2022
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