Add symbol tags as proposed for LSP specification (e.g. visibility tags, static, abstract, etc.) #977 #1149

travkin79 · 2024-11-22T11:34:46Z

Start using new symbol tags as proposed in my microsoft/language-server-protocol#2003, for example, adding private, package, protected, and public visibility tags as well as tags like static, final, abstract, read-only, nullable and non-null. Our motivation comes from our wish to add visibility and other symbol details to the outline view (see discussion #977), but maybe also to the call hierarchy and to the type hierarchy or to other related features / LSP operations.

The PR on the LSP specification requires at least one implementation in a language server and / or a client. We plan to finish a first language server implementation in clangd [1] [2] and a first client implementation in LSP4J, LSP4E, and CDT LSP (which is using clangd).

See microsoft/language-server-protocol#2003
and llvm/llvm-project#167536
and eclipse-lsp4j/lsp4j#856

The PR for updating LSP4E to LSP4J vers. 1.0.0 (#1421) has to be merged before this PR can be merged.

rubenporras · 2024-11-22T12:41:29Z

This would be great it the LSP gets improved and a new version in released.

sebthom · 2025-11-12T18:13:07Z

Hi @travkin79, just checking in - are you planning to finish this PR? It would be much appreciated if you could! 😊

travkin79 · 2025-11-13T11:25:49Z

Hi @sebthom,
Yes, I'd be happy to finish this and related PRs.

The reason for the delay is that the LSP PR requires (in best case) a client implementation and a language server implementation. We planned to implement it for CDT LSP, LSP4E and clangd, but the person implementing the required changes on clangd side stopped working on her/his PR. But in the meanwhile, we found someone else who will finish the work. So, I hope to finish the related PRs, including this one, some time soon.

travkin79 · 2025-11-25T13:33:30Z

Hi @jonahgraham, @sebthom, and @rubenporras,
It seems that LSP4J introduced some new Either types in the API vers. 1.0.0 and LSP4E didn't adapt the changes. Is someone working on that or can give me some hints how the new types should be handled in LSP4E?

Type changes in LSP4J vers. 1.0.0:

TextEdit -> Either<TextEdit, SnippetTextEdit> in TextDocumentEdit class
String -> Either<String, MarkupContent> in Diagnostic class

jonahgraham

TextEdit -> Either<TextEdit, SnippetTextEdit> in TextDocumentEdit class
String -> Either<String, MarkupContent> in Diagnostic class

Background:

Those are the new features in LSP 3.18 (beta support). See https://github.com/eclipse-lsp4j/lsp4j/blob/main/CHANGELOG.md#v100-tbd

See 3.18 spec for more details, which is also in the LSP4J javadocs

How to fix:

Because you are not turning on snippetEditSupport to enable the 3.18 feature (yet), the right thing to do is change things like .getEdits -> getEdits.getLeft.

LMK if that makes sense. It may be a better idea to have a separate PR for the 0.24 -> 1.0 LSP4J change, and I can help write that if the above isn't trivial.

jonahgraham · 2025-11-25T13:36:26Z

org.eclipse.lsp4e.debug/META-INF/MANIFEST.MF

- org.eclipse.lsp4j.jsonrpc;bundle-version="[0.24.0,0.25.0)",
- org.eclipse.lsp4j.jsonrpc.debug;bundle-version="[0.24.0,0.25.0)",
- org.eclipse.lsp4j.debug;bundle-version="[0.24.0,0.25.0)",
+ org.eclipse.lsp4j.jsonrpc;bundle-version="[1.0.0,1.1.0)",


We have improved the API policy for 1.0 going forward to be properly semantic versions. This means the range can safely be:

Suggested change

org.eclipse.lsp4j.jsonrpc;bundle-version="[1.0.0,1.1.0)",

org.eclipse.lsp4j.jsonrpc;bundle-version="[1.0.0,2.0.0)",

Hi @jonahgraham,

It may be a better idea to have a separate PR for the 0.24 -> 1.0 LSP4J change,...

Do we need an issue for the separate PR? I started PR #1421 for that purpose.

Do we need an issue for the separate PR?

No IMHO - but I am not an active committer on LSP4E so I don't know if it is best to just create one to save yourself hassle later.

OK. Then, @rubenporras, please let me know if you want me to create an issue for PR #1421 or if you prefer to create it yourself.

org.eclipse.lsp4e/src/org/eclipse/lsp4e/outline/SymbolsLabelProvider.java

For the sake of simplicity, for now, we only use the left argument in Either tuples, i.e. the types that we used in earlier versions.

org.eclipse.lsp4e/src/org/eclipse/lsp4e/ui/LSPImages.java

travkin79 · 2025-11-27T13:54:04Z

org.eclipse.lsp4e/src/org/eclipse/lsp4e/ui/LSPImages.java

+	// TODO Do we have to dispose all images in the image caches?
+
 	private static final Map<java.awt.Color, Image> colorToImageCache = new HashMap<>();
+
+	/**
+	 * Cache for symbol images with various overlays and / or an underlay.
+	 *
+	 * First key: the element's kind (e.g. class or method);
+	 * Second key: hash value calculated for a set of overlay image descriptors,
+	 *             see {@link #getImageWithOverlays(SymbolKind, ImageDescriptor[])};
+	 * Value: the base image with overlays and an optional underlay combined in one image.
+	 */
+	private static final Map<SymbolKind, Map<Integer, Image>> overlayImagesCache = new HashMap<>();


Hi @jonahgraham,
Do we have to dispose the images cached here? It seems that images should be disposed when the Display used to create them is being disposed. What would be the best way to do that?

The short answer is register with org.eclipse.swt.widgets.Display.disposeExec(Runnable) to dispose of images when the display is disposed.

You can also look at how org.eclipse.jface.resource.ImageRegistry handles it.

PS I dodged the "Do we have to dispose the images cached here? " part of the question - but the answer is yes in theory, in practice if the test suites aren't making additional displays, chances are it never matters in practice. However the non-dispose listener may warn about non-disposed images. Perhaps it is already on colorToImageCache entries, but as it happens on shutdown no one paid attention/noticed?

Run with -Dorg.eclipse.swt.graphics.Resource.reportNonDisposed=true to get the warnings.

Ok, I hope to have solved it by disposing the cached images on bundle / plug-in stop. I tried to start Eclipse with -Dorg.eclipse.swt.graphics.Resource.reportNonDisposed=true, but did not see any warning or error message if images were not disposed.

travkin79 · 2025-11-27T14:07:02Z

org.eclipse.lsp4e/src/org/eclipse/lsp4e/ui/LSPImages.java

+		@Nullable ImageDescriptor[] overlays = {
+				visibilityImageDescriptor, topRightOverlayDescriptor,
+				severityImageDescriptor, bottomRightOverlayDescriptor,
+				deprecatedImageDescriptor};


Hi @sebthom and @jonahgraham,
Is it correct here to use @Nullable this way? I want to express that the variable overlays cannot be null, but the array entries can be null.

I think it is @NonNull ImageDescriptor @Nullable [] - but not really very experienced in this area.

That's what I also started with, but for some reason I get an error message saying that @NonNull is not allowed here. 🤔

I didn't try it - hopefully @sebthom has a good answer as he has been doing a great job of maintaining the nullness analysis.

I think, I solved it now. It turns out, I erroneously used an annotation from LSP4J, not a JDT annotation. In addition, the null checks in Eclipse seem to have problems to correctly check nullabililty for array variables and their entries.

travkin79 mentioned this pull request Dec 5, 2024

Add symbol tags as proposed for LSP specification (e.g. visibility tags, static, abstract, etc.) eclipse-lsp4j/lsp4j#856

Merged

travkin79 force-pushed the feature/new-symbol-tags branch 2 times, most recently from 645d293 to ea5b00a Compare November 25, 2025 13:23

jonahgraham reviewed Nov 25, 2025

View reviewed changes

travkin79 mentioned this pull request Nov 25, 2025

Adapt LSP4E to LSP4J vers. 1.0.0 #1421

Draft

travkin79 force-pushed the feature/new-symbol-tags branch from ea5b00a to e08aed6 Compare November 25, 2025 15:31

github-advanced-security bot found potential problems Nov 25, 2025

View reviewed changes

org.eclipse.lsp4e/src/org/eclipse/lsp4e/outline/SymbolsLabelProvider.java Fixed Show fixed Hide fixed

travkin79 force-pushed the feature/new-symbol-tags branch 2 times, most recently from 5d2dc08 to 0131fe3 Compare November 26, 2025 16:49

travkin79 added 3 commits November 27, 2025 14:19

Use LSP4J nightly builds in target platform, update version ranges

add9ef8

Adapt to new LSP4J v. 1.0.0 API

ef34a69

For the sake of simplicity, for now, we only use the left argument in Either tuples, i.e. the types that we used in earlier versions.

Bump plug-in versions

ee645ca

travkin79 force-pushed the feature/new-symbol-tags branch from 0131fe3 to 4abe75c Compare November 27, 2025 13:33

github-advanced-security bot found potential problems Nov 27, 2025

View reviewed changes

org.eclipse.lsp4e/src/org/eclipse/lsp4e/ui/LSPImages.java Fixed Show fixed Hide fixed

travkin79 force-pushed the feature/new-symbol-tags branch from 4abe75c to eec3214 Compare November 27, 2025 13:44

travkin79 commented Nov 27, 2025

View reviewed changes

Use symbol tags in outline view to display visibility and other details

9746520

travkin79 force-pushed the feature/new-symbol-tags branch from eec3214 to 9746520 Compare November 28, 2025 12:32

	org.eclipse.lsp4j.jsonrpc;bundle-version="[1.0.0,1.1.0)",
	org.eclipse.lsp4j.jsonrpc;bundle-version="[1.0.0,2.0.0)",

Add symbol tags as proposed for LSP specification (e.g. visibility tags, static, abstract, etc.) #977 #1149

Are you sure you want to change the base?

Add symbol tags as proposed for LSP specification (e.g. visibility tags, static, abstract, etc.) #977 #1149

Uh oh!

Conversation

travkin79 commented Nov 22, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rubenporras commented Nov 22, 2024

Uh oh!

sebthom commented Nov 12, 2025

Uh oh!

travkin79 commented Nov 13, 2025

Uh oh!

travkin79 commented Nov 25, 2025

Uh oh!

jonahgraham left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

travkin79 Nov 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

travkin79 commented Nov 22, 2024 •

edited

Loading

travkin79 Nov 25, 2025 •

edited

Loading