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

[Feature Request] Provide method for converting callstack entry to location #1202

Closed
yyoncho opened this issue Oct 8, 2019 · 8 comments · Fixed by #1584
Closed

[Feature Request] Provide method for converting callstack entry to location #1202

yyoncho opened this issue Oct 8, 2019 · 8 comments · Fixed by #1584
Assignees

Comments

@yyoncho
Copy link
Contributor

yyoncho commented Oct 8, 2019

This will allow the clients to make the links in the output clickable:
E. g.

	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)

I think that it might be possible to implement this on client-side by parsing the message and then using workspace/symbols but maybe it makes more sense to implement that on the server.

@fbricon
Copy link
Contributor

fbricon commented Oct 16, 2019

@jdneo @yaohaizh @testforstephen you guys might want to look into this, as I'm sure this could be useful for the vscode java debugger

@testforstephen
Copy link
Contributor

The java debugger has provided our own source look up logic, probably it's able to port back to jdt.ls.

@yyoncho
Copy link
Contributor Author

yyoncho commented Sep 21, 2020

The java debugger has provided our own source look up logic, probably it's able to port back to jdt.ls.

@testforstephen can you point me to this logic?

@testforstephen
Copy link
Contributor

  • Use regular expression to resolve the fully qualified class name and the relative source path, see the code.
  • Search the source path in the source containers. See the code.

@jdneo
Copy link
Contributor

jdneo commented Oct 27, 2020

I'm working on this.

@rgrunber
Copy link
Contributor

Seems reasonable. Eclipse does something pretty similar in the Java Stacktrace Console . You can also see some of the code in JavaStackTraceHyperlink.java. Though it's in jdt.debug.ui/jdt.debug it could still serve as a guide.

@testforstephen
Copy link
Contributor

Have a look at JavaStackTraceHyperlink.java, it will search the type with search engine first, if no result, then fall back to resolveSourceElement, which is equivalent to search in the source containers used by @jdneo PR.

One benefit of using search engine is it's more efficient since it's based on indexer. But there are some cases search engine doesn't support well, such as anonymous class and class name with $. Source container approach can cover more corner cases. Maybe we can also combine these two approaches together.

@rgrunber
Copy link
Contributor

rgrunber commented Nov 2, 2020

In that case, I would be fine with just submitting the current "source container" logic and add the SearchEngine logic at a later point (if performance demands it).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants