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

GH-28: Added support for the super- and subtype hierarchies. #823

Closed
wants to merge 1 commit into from

Conversation

kittaakos
Copy link

@kittaakos kittaakos commented Oct 9, 2018

Note: This item depends on eclipse-lsp4j/lsp4j#272 due to required API changes. Still, this PR is ready for review/preview. Done.

Closes: #28.

Signed-off-by: Akos Kitta [email protected]

screencast 2018-10-11 15-18-32

46809098-15c30880-cd6e-11e8-8146-fcdc90f6721b

For reviewers:

  • I start working on a client implementation, once it is available, I will update this PR. A client implementation with Eclipse Theia is available here.
  • Why did I add org.eclipse.wst.xml_ui.feature.feature.group to the TP? The TP related change is not required anymore. See GH-28: Added support for the super- and subtype hierarchies. #823 (review).
    • LSP4J depends on Xtext/Xtend 2.15.
    • Xtext/Xtend 2.15 is not available from the http://download.eclipse.org/releases/photon/ p2 site.
    • But org.jboss.tools.maven.apt.feature.feature.group depends on org.eclipse.wst.xml.ui that we used to pull from http://download.eclipse.org/releases/photon/ under the hood.
    • I had to explicitly declare the org.eclipse.wst.xml_ui.feature.feature.group feature dependency to fulfill the missing o.e.wst.xml.ui plug-in.

Edit: Updated the section for the TP.

</location>
<location includeAllPlatforms="false" includeConfigurePhase="false" includeMode="planner" includeSource="true" type="InstallableUnit">
<unit id="org.eclipse.xtend.sdk.feature.group" version="2.14.0.v20180523-0937"/>
<unit id="org.eclipse.xtext.sdk.feature.group" version="2.14.0.v20180523-0937"/>
<unit id="org.eclipse.wst.xml_ui.feature.feature.group" version="3.10.0.v201804210200"/>
Copy link
Contributor

Choose a reason for hiding this comment

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

should not be necessary anymore, since we now only add the m2e-apt core bundle to the TP 74a0993

@kittaakos
Copy link
Author

I have updated this PR based on the feedback we got for the LSP modifications.

I am currently experiencing build issues locally, it might be related to Xtext.

@fbricon
Copy link
Contributor

fbricon commented Jan 22, 2019

How can I test it?

* The location, encapsulating the range enclosing this symbol not including
* leading/trailing whitespace but everything else like comments.
*/
public static Location getFullLocation(IJavaElement element) throws JavaModelException {
Copy link
Contributor

Choose a reason for hiding this comment

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

similar static methods related to location computation live in JDTUtils. I reckon it's getting bloated over time, so we might get a dedicated LocationUtils class to handle all that

return null;
}
try {
Location fullLocation = DocumentSymbolHandler.getFullLocation(type);
Copy link
Contributor

Choose a reason for hiding this comment

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

should not reference DocumentSymbolHandler here. use utility class instead


public TypeHierarchyHandler(PreferenceManager preferenceManager) {
this.preferenceManager = preferenceManager;
enabled = Suppliers.memoize(() -> this.preferenceManager.getClientPreferences().isTypeHierarchySupported());
Copy link
Contributor

@fbricon fbricon Jan 22, 2019

Choose a reason for hiding this comment

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

not convinced this simple call needs to be memoized

@fbricon
Copy link
Contributor

fbricon commented Jan 22, 2019

you might want to change copyright headers for new files to 2019.

@kittaakos kittaakos changed the title GH-28: Added support for the super- and subtype hierarchies. [WIP] GH-28: Added support for the super- and subtype hierarchies. Jan 22, 2019
@kittaakos
Copy link
Author

How can I test it?

It's not yet ready, sorry for the noise. I added the [WIP] tag to the title. I had to push to see if the build failure is local or not.

I will update this PR once more with some hints on how to try it.

@kittaakos
Copy link
Author

How can I test it?

You can build it from source, but you need Python 2.x, yarn, etc.. or you could try to open it in Gitpod.

  1. Open in Gitpod
  2. Once the build is finished, you can start the modified version of Theia with the adjusted JDT LS.
    Execute the yarn --cwd ./examples/browser start --hostname 0.0.0.0 --port 3000 in the terminal.

screen shot 2019-01-25 at 16 27 58

  1. Click on Open Browser and you have to wait a bit.
    screen shot 2019-01-25 at 16 28 07

  2. When you can see the welcome screen, you have to open a new terminal. It is either with Ctrl+Shift+` or from the Terminal > New Terminal menu.

  3. Clone the JDT LS source by executing cd /workspace/ && git clone https://github.com/eclipse/eclipse.jdt.ls.git in the new terminal. (You can get any other Java source.)

  4. Open a new workspace.
    screen shot 2019-01-25 at 17 07 18
    screen shot 2019-01-25 at 17 07 26
    screen shot 2019-01-25 at 17 07 35

  5. Once your workspace is up in Theia and the Java LS build has finished, open any Java files.
    You can trigger the type hierarchy either with Ctrl/Cmd+Alt+H or from the editor's context menu.
    screen shot 2019-01-25 at 17 13 35

Note, if the Type Hierarchy view is active, and has input, it will flip the type hierarchy direction.
screencast 2019-01-25 17-15-17

If you have any question, or you stuck, let me know.

@kittaakos
Copy link
Author

An easier way; here is Gitpod snapshot containing all the steps I have described above.
After clicking the link, select Open Browser from the top, and you can open (Ctrl/Cmd+P) any Java files from the workspace to try out the feature.

@kittaakos kittaakos changed the title [WIP] GH-28: Added support for the super- and subtype hierarchies. GH-28: Added support for the super- and subtype hierarchies. Jan 25, 2019
*/
private TypeHierarchyItem shallowCopy(TypeHierarchyItem other) {
TypeHierarchyItem copy = new TypeHierarchyItem();
other.setName(other.getName());
Copy link
Author

Choose a reason for hiding this comment

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

FIXME: must be copy instead of other.

@kittaakos
Copy link
Author

I have rebased this PR from the master and updated the LSP4J dependency from 0.6.0 to 0.7.0. I also made the necessary API changes due to the LSP modifications. This PR is ready for the review.

Please note, although the proposed LSP extension has not been accepted by MS yet, this PR complies the proposed changes.

@yudar1024
Copy link

wait this feature long time.

@yudar1024
Copy link

@fbricon can some one handle the confilict files? wait this feature long time?

@fbricon
Copy link
Contributor

fbricon commented Oct 24, 2019

@yudar1024 I want to wait for the spec to be finalized before merging this feature. See microsoft/vscode-languageserver-node#426

@yudar1024
Copy link

@fbricon can you merge first to let developer can use it in early time like clangd, merge it at this time or after spec be finalize, we both need change the code if the spec make some change. but if we merge at this time , at least it can make vsc more efficient early

@CsCherrYY
Copy link
Contributor

Hi @kittaakos

Are you still interested in this feature? I think it's especially useful and I'm interested in it.

I found you closed microsoft/vscode-languageserver-node#426 which is a proposal of type hierarchy in LSP. Although it will not be available in LSP recently, VS Code allows extensions to contribute to the tree view and here is a sample.

We could put the type hierarchy in the tree view, use a private command to exchange data instead of LSP currently. What do you think about it?

@CsCherrYY
Copy link
Contributor

CsCherrYY commented Jan 14, 2021

@kittaakos @fbricon

I'm going to implement this feature and make it available first. In the future, we can move to LSP once it supports type hierarchy.

I notice the data models such as TypeHierarchyItem, TypeHierarchyParams and ResolveTypeHierarchyItemParams are available since lsp4j#273. I'd like to start with these models and use a delegate command to communicate between client and server.

In VS Code side, References Viewlet API offers an API to contribute to the reference view. Type hierarchy data can be shown in the reference view with this, just like how call hierarchy works today.

Do you have any comment or suggestion on this?

@fbricon
Copy link
Contributor

fbricon commented Apr 16, 2021

Superseded by #1656

@fbricon fbricon closed this Apr 16, 2021
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.

Support for Type Hierarchy
4 participants