LSP 3.18 - Symbol Tags #167536

ratzdi · 2025-11-11T17:04:25Z

Implementation of the issues microsoft/language-server-protocol#2003 and clangd/clangd#2123. Continuation of #113669.

Related Follow-up PR: #170103

github-actions · 2025-11-11T17:04:43Z

Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this page.

If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using @ followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers.

If you have further questions, they may be answered by the LLVM GitHub User Guide.

You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums.

github-actions · 2025-11-18T06:47:55Z

✅ With the latest revision this PR passed the C/C++ code formatter.

…rarchy.

Added tags node in the expected JSON output.

ratzdi · 2025-12-03T15:01:03Z

Hi @kadircet, @llvm-beanz, I would be very happy to see you as a reviewer!

HighCommander4

Thanks for the PR and sorry for the long turnaround time in responding.

I have two high-level pieces of feedback.

First, I think it would be nice to cut down on the amount of new "API" we're exposing in AST.h, as well as some of the code duplication between symbol tags and highlighting modifiers.

(To give an example of what code duplication I'm referring to: it's not obvious why the logic for assigning the Declaration tag checks for UnresolvedUsingValueDecl. This comment explains it nicely, but rather than asking for the comment to be duplicated, I'd rather avoid the check itself being duplicated in the first place.)

Here's a specific proposal:

Establish a "packed" representation for symbol tags. This can be as simple as using SymbolTags = uint32_t; , with the interpretation that if tag N is present, then the bit 1 << N is set in the value.
- (The reason for having a packed representation at all is so that we don't impose the cost of allocating vectors onto all consumers including semantic highlighting.)
Have the public API in AST.h just be SymbolTags computeSymbolTags(Decl*) or similar.
The FindSymbols code can call computeSymbolTags(), and unpack the result into a vector<SymbolTag>.
- (If we later have multiple requests return a vector<SymbolTag>, it's fine to expose a function that returns a vector<SymbolTag> in AST.h as well.)
The SemanticHighlighting code can also call computeSymbolTags(), and use a mapping from SymbolTag to HighlightingModifier to convert them to highlighting modifiers. (It's fine to do this only for the subset of modifiers which are also symbol tags. The remaining modifiers can be added individually.)

This way, the logic (including the UnresolvedUsingValueDecl check) can remain centralized in the implementation of computeSymbolTags().

How does that sound?

Second, regarding testing strategy: given how relatively hard to read lit tests are, we generally use lit tests as a basic "smoke test" that the protocol conversions are working fine, while putting interesting logic into unit tests.

In this case, I think it would be good to have some unit tests that exercise the new computeSymbolTags() API. They don't need to be extensive, I think it's sufficient to test on a small piece of code similar to the one that symbol-tags.test sends in its didOpen, that the computed tags for various symbols are the expected ones.

To make this as easy as possible, I would suggest using the existing DocumentSymbols test fixture (example test), with a new matcher added around here that checks the symbol tags. (This will exercise the computeSymbolTags() API indirectly via its use in the FindSymbols feature, but I think that's good enough.) Happy to go into more details about this if it's not clear what I'm suggesting.

HighCommander4 · 2025-12-29T07:00:06Z

clang-tools-extra/clangd/Protocol.h

 };
 llvm::json::Value toJSON(const CodeAction &);

+enum class SymbolTag {


If I'm understanding this correctly, the list and order here is coming from microsoft/language-server-protocol#2003.

Can we link to that PR from a comment here? That makes it clear that we're implementing something that's not in the spec yet, and serves as a reminder for us to update the implementation if the spec ends up being different from the current list in the PR.

I'm not seeing the requested comment.

HighCommander4 · 2026-01-14T06:29:35Z

What's unclear to me is when the case might occur in FindSymbols, quote "If we later have multiple requests return a vector, it's fine to expose a function that returns a vector in AST.h as well.)"?

For example, if we later give TypeHierarchyItem a vector<SymbolTag> as well (as it seems you're planning to do in #170103), it will be convenient to have a function that returns a vector<SymbolTag> live in AST.h rather than FindSymbols.cpp (so that the type hierarchy code can reuse it).

Is calling computeSymbolTags from SemanticHighlighting a hypothetical scenario, or do you see adjustments I could make within this PR?

I was thinking doing it in this PR (as I see you're already doing in your draft update), to avoid the code duplication mentioned earlier.

HighCommander4

(I know the patch is a draft but I took a quick look and spotted a few things.)

HighCommander4 · 2026-01-14T06:36:53Z

clang-tools-extra/clangd/FindSymbols.cpp

+  const auto SymbolTags = computeSymbolTags(ND);
+  std::vector<SymbolTag> Tags;
+
+  if (SymbolTags & toSymbolTagBitmask(SymbolTag::Deprecated))


We should be able to do this with a loop.

HighCommander4 · 2026-01-14T06:54:14Z

clang-tools-extra/clangd/SemanticHighlighting.h


+
+// Whether T is const in a loose sense - is a variable with this type readonly?
+bool isConst(QualType T);


Part of my motivation in asking not to have these granular functions in AST.h, is to avoid having them in any header file. They should be able to live wherever the implementation that computes symbol tags lives, in this case FindSymbols.cpp.

HighCommander4 · 2026-01-14T07:10:26Z

clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp

 MATCHER_P(withKind, Kind, "") { return arg.kind == Kind; }
 MATCHER_P(withDetail, Detail, "") { return arg.detail == Detail; }
 MATCHER_P(symRange, Range, "") { return arg.range == Range; }
+MATCHER_P(withSymbolTag, Tag, "") { return llvm::is_contained(arg.tags, Tag); }


Instead of doing a separate lookup for each tag (quadratic in the number of tags), we can check them in a single go with:

Matcher<DocumentSymbol> withSymbolTags(std::initializer_list<SymbolTag> Tags) { return Field(&DocumentSymbol::tags, ElementsAreArray(Tags)); }

and then

withSymbolTags({SymbolTag::Abstract, SymbolTag::Definition})

You can also use UnorderedElementsAreArray if you'd prefer.

… Declarations and Definitions.

Refactoring on getSymbolTags and computeSymbolTags. Improved SymbolTags test.

HighCommander4 · 2026-01-15T08:04:37Z

clang-tools-extra/clangd/XRefs.cpp

  HI.name = printName(Ctx, ND);
  // FIXME: Populate HI.detail the way we do in symbolToHierarchyItem?
  HI.kind = SK;
+  HI.tags = getSymbolTags(ND);


Is this change intended to be here, or in #170103?

Likewise for the change to TypeHierarchyItem in Protocol.h.

This change is intended in #170103. I will delete this line. In this PR, for the first, we collect the symbol tags in the method documentSymbol. More will follow in #170103.

HighCommander4 · 2026-01-15T08:12:44Z

clang-tools-extra/clangd/Protocol.h

 };
 llvm::json::Value toJSON(const CodeAction &);

+enum class SymbolTag {


I'm not seeing the requested comment.

HighCommander4 · 2026-01-15T08:16:09Z

clang-tools-extra/clangd/FindSymbols.cpp

+//
+// This is confusing, and maybe we should use another name, but because "static"
+// is a standard LSP modifier, having one with that name has advantages.
+bool isStatic(const Decl *D) {


Please put the helpers (i.e. anything not exposed in the header) in the anonymous namespace.

HighCommander4 · 2026-01-15T08:16:56Z

clang-tools-extra/clangd/SemanticHighlighting.h


+// Indicates whether declaration D is a unique definition (as opposed to a
+// declaration).
+bool isUniqueDefinition(const NamedDecl *Decl);


This doesn't need to be exposed in the header.

HighCommander4 · 2026-01-15T08:30:39Z

clang-tools-extra/clangd/FindSymbols.cpp

+    // Do not treat an UnresolvedUsingValueDecl as a declaration.
+    // It's more common to think of it as a reference to the
+    // underlying declaration.
+    Result |= toSymbolTagBitmask(SymbolTag::Declaration);


I'm a bit unclear on the intended semantics of the Declaration tag, especially as the FindSymbols call site is passing IsDecl = true.

Is the intention that every document symbol is a Declaration (except UnresolvedUsingValueDecl which is a minor edge case)?

The wording in the PR -- specifically "Render a symbol as definition (in contrast to declaration)" -- makes me think perhaps Declaration should only be set for things that are not a Definition?

(I have some ideas about cleaning up the API to avoid the IsDecl parameter, but we first need to understand what the behaviour we're trying to implement is.)

In SemanticHighlighting.cpp (main branch Line 1132) there is an if-statement that I have kept (otherwise breaking tests) in my work (without precise knowledge of the purpose of the condition)

if (R.IsDecl) { // Do not treat an UnresolvedUsingValueDecl as a declaration. // It's more common to think of it as a reference to the // underlying declaration. if (!isa<UnresolvedUsingValueDecl>(Decl)) Tok.addModifier(HighlightingModifier::Declaration); if (isUniqueDefinition(Decl)) Tok.addModifier(HighlightingModifier::Definition); }

now the if-statement is located in computeSymbolTags
const auto SymbolTags = computeSymbolTags(*Decl, R.IsDecl);

and the lines

... const auto SymbolTags = computeSymbolTags(*Decl, R.IsDecl); ... if (SymbolTags & toSymbolTagBitmask(SymbolTag::Declaration)) Tok.addModifier(HighlightingModifier::Declaration); if (SymbolTags & toSymbolTagBitmask(SymbolTag::Definition)) Tok.addModifier(HighlightingModifier::Definition); ...

replacing the code block, mentioned above.

The wording in the PR -- specifically "Render a symbol as definition (in contrast to declaration)" -- makes me think perhaps Declaration should only be set for things that are not a Definition?

When we decide to either ... or, some tests will break.

The wording in the PR -- specifically "Render a symbol as definition (in contrast to declaration)" -- makes me think perhaps Declaration should only be set for things that are not a Definition?

When we decide to either ... or, some tests will break.

I'm assuming you're referring to semantic highlighting tests.

I'm talking here about the expected behaviour of textDocument/documentSymbol.

Say you're a client like Eclipse, and you send a textDocument/documentSymbol request, e.g. for the purpose of populating an Outline view. Are there any cases (ignoring the edge case of UnresolvedUsingValueDecl) where you'd want a returned symbol not to have the Declaration symbol tag set?

There are no such cases.

The code block below arises from the assumption that a definition is always also a declaration. A definition cannot exist without a declaration. I now think that my previous assumption is incorrect, especially in this context.

if (IsDecl && not isa<UnresolvedUsingValueDecl>(ND)) { // Do not treat an UnresolvedUsingValueDecl as a declaration. // It's more common to think of it as a reference to the // underlying declaration. Result |= toSymbolTagBitmask(SymbolTag::Declaration); if (IsDef) Result |= toSymbolTagBitmask(SymbolTag::Definition); }

There are no such cases.

Ok.

(This makes me question a bit why the Declaration modifier exists at all -- surely the authors of the LSP proposal weren't thinking of using-declarations -- but perhaps that's something we can follow up on in microsoft/language-server-protocol#2003.)

So, in terms of implementation strategy, I would suggest the following:

Remove the IsDecl parameter from computeSymbolTags() (keep the implementation as if it was true)

In SemanticHighlighting.cpp, do:
if (R.IsDecl && (SymbolTags & toSymbolTagBitmask(SymbolTag::Declaration))) Tok.addModifier(HighlightingModifier::Declaration);

HighCommander4 · 2026-01-15T08:35:36Z

clang-tools-extra/clangd/FindSymbols.cpp

+  // Iterate through SymbolTag enum values and collect any that are present in
+  // the bitmask. SymbolTag values are in the numeric range
+  // [Deprecated .. ReadOnly].
+  constexpr unsigned MinTag = static_cast<unsigned>(SymbolTag::Deprecated);


It may be more robust to add two special enum members:

enum class SymbolTag { Deprecated = 1, ... ReadOnly = 20, // Update as needed FirstTag = Deprecated, LastTag = ReadOnly };

and use those here.

HighCommander4 · 2026-01-15T08:37:03Z

clang-tools-extra/clangd/FindSymbols.h

 class SymbolIndex;

+/// A bitmask type representing symbol tags.
+using SymbolTags = uint32_t;


Let's static_assert(SymbolTag::LastTag < 32). If the number of tags ever grows beyond that, it will serve as a reminder to change this to uint64_t.

HighCommander4 · 2026-01-15T08:39:57Z

clang-tools-extra/clangd/unittests/FindSymbolsTests.cpp

+TEST(DocumentSymbolsTest, SymbolTags) {
+  TestTU TU;
+  Annotations Main(R"(
+      class A {


It would be nice to test at least the amount of code we have in symbol-tags.test, i.e.

class AbstractClass{\n public:\n virtual ~AbstractClass() = default;\n virtual void f1() = 0;\n void f2() const;\n protected: \n void f3(){}\n private: \n static void f4(){} \n }; void AbstractClass::f2() const {} \n class ImplClass final: public AbstractClass { \n public: \n void f1() final {}};"
}}}

If you don't want to have that full code in two places, I'd rather have the shorter code in the lit test and the longer code here.

(Rationale: if we make tweaks to the tag behaviour, we'll want to accompany them with tests, and they'll be more readable as unit tests.)

Refactored unit and integration tests. Robust SymbolTag declaration. Static assert of the symbol tag bit-mask's size. And other minor improvements...

HighCommander4 · 2026-01-18T07:10:34Z

clang-tools-extra/clangd/SemanticHighlighting.cpp

+
+          const auto SymbolTags = computeSymbolTags(*Decl, R.IsDecl);
+
+          if (SymbolTags & toSymbolTagBitmask(SymbolTag::Deprecated))


Could we do something like declare a map at the top level in getSemanticHighlightins:

llvm::DenseMap<SymbolTag, HighlightingModifier> TagToModifierMap { {SymbolTag::Deprecated, HighlightingModifier::Deprecated}, // other mappings as appropriate };

and then loop through the map here?

(Declaration can be omitted from the map and handled explicitly due to the extra logic discussed in the other comment.)

HighCommander4 · 2026-01-18T07:16:08Z

clang-tools-extra/clangd/FindSymbols.cpp

+    // Do not treat an UnresolvedUsingValueDecl as a declaration.
+    // It's more common to think of it as a reference to the
+    // underlying declaration.
+    Result |= toSymbolTagBitmask(SymbolTag::Declaration);


There are no such cases.

Ok.

(This makes me question a bit why the Declaration modifier exists at all -- surely the authors of the LSP proposal weren't thinking of using-declarations -- but perhaps that's something we can follow up on in microsoft/language-server-protocol#2003.)

So, in terms of implementation strategy, I would suggest the following:

Remove the IsDecl parameter from computeSymbolTags() (keep the implementation as if it was true)

In SemanticHighlighting.cpp, do:
if (R.IsDecl && (SymbolTags & toSymbolTagBitmask(SymbolTag::Declaration))) Tok.addModifier(HighlightingModifier::Declaration);

refactored computeSymbolTags - no IsDecl is needed, refactored getSemanticHighlightings - intro map for tags and modifiers,

HighCommander4

Thanks -- looking pretty good, just minor comments remaining.

HighCommander4 · 2026-01-20T07:06:21Z

clang-tools-extra/clangd/FindSymbols.h

 /// same order that they appear.
 llvm::Expected<std::vector<DocumentSymbol>> getDocumentSymbols(ParsedAST &AST);

+/// Returns the symbol tags for the given declaration.


Maybe add:

/// This is a wrapper around computeSymbolTags() which unpacks /// the tags into a vector.

and move the declaration below computeSymbolTags().

HighCommander4 · 2026-01-20T07:09:09Z

clang-tools-extra/clangd/AST.cpp


 #include "AST.h"

+#include "SemanticHighlighting.h"


nit: This include is not necessary any more.

I would suggest removing the changes to AST.cpp and call-hierarchy.test from this diff altogether.

HighCommander4 · 2026-01-20T07:11:05Z

clang-tools-extra/clangd/Protocol.h

  SymbolKind kind;

+  /// The symbol tags for this item.
+  std::vector<SymbolTag> tags;


Per previous discussion, this change to TypeHierarchyItem shouldn't be in this patch

HighCommander4 · 2026-01-20T07:12:47Z

clang-tools-extra/clangd/FindSymbols.cpp

 namespace clangd {

+namespace {
+SymbolTags toSymbolTagBitmask(const SymbolTag ST) {


I think it makes sense to expose this function in FindSymbols.h, given that SemanticHighlighting.cpp also uses it (and more generally, that it's needed to make practical use of the result of computeSymbolTags())

HighCommander4 · 2026-01-20T07:21:27Z

clang-tools-extra/clangd/SemanticHighlighting.cpp

+
+          const auto SymbolTags = computeSymbolTags(*Decl);
+
+          static const llvm::DenseMap<SymbolTag, HighlightingModifier>


This code can be run concurrently from multiple threads, so I don't think we can make it static.

But maybe we can make it static thread_local? We have existing uses of that in clangd code so it should work.

HighCommander4 · 2026-01-20T07:22:57Z

clang-tools-extra/clangd/SemanticHighlighting.h


 #include "Protocol.h"
+
+#include "clang/AST/TypeBase.h"


Changes to this file can be dropped from the patch as well.

They're still here.

- obsolete includes, - public toSymbolTagBitmask, - removed tags from TypeHierarchyItem, - thread_local map in getSemanticHighlightings - minor improvements

HighCommander4

Thanks! LGTM with final nits (drop changes to AST.h and SemanticHighlighting.h).

HighCommander4 · 2026-01-20T21:45:39Z

clang-tools-extra/clangd/AST.h

 #include "index/Symbol.h"
 #include "index/SymbolID.h"
 #include "clang/AST/Decl.h"
-#include "clang/AST/DeclObjC.h"


nit: This removal seems like an include-what-you-use violation, as types like ObjCMethodDecl are referenced in this patch.

Just drop this?

HighCommander4 · 2026-01-20T21:48:18Z

clang-tools-extra/clangd/SemanticHighlighting.h


 #include "Protocol.h"
+
+#include "clang/AST/TypeBase.h"


They're still here.

- removed obsolete forward-decl and includes - restored include

HighCommander4 · 2026-01-22T08:18:25Z

clang-tools-extra/clangd/SemanticHighlighting.h


 #include "Protocol.h"
 #include "llvm/ADT/StringRef.h"
-#include "llvm/Support/raw_ostream.h"


There's still a change to SemanticHighlighting.h here.

(I would have fixed this for you myself and merged, but it looks like "Maintainers are allowed to edit this pull request" is not checked, so I can't 🤷 )

github-actions · 2026-01-23T03:00:34Z

@ratzdi Congratulations on having your first Pull Request (PR) merged into the LLVM Project!

Your changes will be combined with recent changes from other authors, then tested by our build bots. If there is a problem with a build, you may receive a report in an email or a comment on this PR.

Please check whether problems have been caused by your change specifically, as the builds can include changes from many authors. It is not uncommon for your change to be included in a build that fails due to someone else's changes, or infrastructure issues.

How to do this, and the rest of the post-merge process, is covered in detail here.

If your change does cause a problem, it may be reverted, or you can revert it yourself. This is a normal part of LLVM development. You can fix your changes and open a new PR to merge them again.

If you don't get any reports, no action is required from you. Your changes are working as expected, well done!

…llvm#167536) Implements support for symbol tags proposed for LSP 3.18 in microsoft/language-server-protocol#2003, in the `documentSymbols` and `workspace/symbols` requests. Fixes clangd/clangd#2123. --------- Co-authored-by: chouzz <zhouhua258@outlook.com> Co-authored-by: Dimitri Ratz <dimitri.ratz@thinkdigital.cc>

chouzz added 4 commits November 11, 2025 17:34

[clangd] Support symbolTags for document symbol

103b18f

Fix access for class method

18c71ac

Support Declaration and Definition tags

af6491c

Remove constant tag

baa29b1

nightlark mentioned this pull request Nov 11, 2025

Request Commit Access For ratzdi #167469

Closed

ratzdi force-pushed the users/ratzdi/symbol_tags branch from 8d5dd8b to 60a56c9 Compare November 12, 2025 08:12

Fix test

64d5a36

ratzdi force-pushed the users/ratzdi/symbol_tags branch from 60a56c9 to 64d5a36 Compare November 12, 2025 08:17

Dimitri Ratz and others added 4 commits November 12, 2025 16:14

Tagging final methods and classes

49551b5

Checks the extraction of symbol tags

8a4b314

Merge branch 'main' into users/ratzdi/symbol_tags

f29267e

Docu update

49574d8

ratzdi mentioned this pull request Nov 17, 2025

[clangd] Support symbolTags for document symbol #113669

Closed

HighCommander4 self-requested a review November 18, 2025 06:47

travkin79 mentioned this pull request Nov 18, 2025

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

Draft

Fix code format.

a5a8555

ratzdi force-pushed the users/ratzdi/symbol_tags branch from 53c9892 to a5a8555 Compare November 18, 2025 10:46

travkin79 mentioned this pull request Nov 19, 2025

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

Merged

ratzdi added 2 commits November 19, 2025 16:35

Merge branch 'main' into users/ratzdi/symbol_tags

979f7e7

Merge branch 'main' into users/ratzdi/symbol_tags

b52210f

ratzdi marked this pull request as ready for review November 19, 2025 15:41

Dimitri Ratz and others added 3 commits November 27, 2025 15:13

Fill symbol tags for the response CallHierarchyItem of prepareCallHie…

8131e6f

…rarchy.

Fix call-hierarchy.test

317eb1d

Added tags node in the expected JSON output.

Merge branch 'main' into users/ratzdi/symbol_tags

d899c71

Merge branch 'main' into users/ratzdi/symbol_tags

1b39d9c

ratzdi mentioned this pull request Dec 16, 2025

Symbol tags in SymbolInformation, WorkspaceSymbol, CallHierarchyItem and TypeHierarchyItem #170103

Open

HighCommander4 requested changes Dec 29, 2025

View reviewed changes

HighCommander4 reviewed Jan 14, 2026

View reviewed changes

Dimitri Ratz added 5 commits January 14, 2026 09:07

Overload computeSymbolTags to encapsulate the proper determination of…

6f0deff

… Declarations and Definitions.

Relocated computeSymbolTags to the module FindSymbols.

ea5fd1c

Refactoring on getSymbolTags and computeSymbolTags. Improved SymbolTags test.

Fixed tests.

438b02f

Includes clean-up.

53a8c8f

Removed computeSymbolTags(const NamedDecl &ND) from public API.

31dc8a5

ratzdi marked this pull request as ready for review January 14, 2026 14:32

HighCommander4 requested changes Jan 15, 2026

View reviewed changes

Fix format.

04144e5

ratzdi marked this pull request as draft January 15, 2026 13:50

Dimitri Ratz added 2 commits January 15, 2026 16:08

Review findings:

64978c3

Refactored unit and integration tests. Robust SymbolTag declaration. Static assert of the symbol tag bit-mask's size. And other minor improvements...

Fix test.

b265a9c

HighCommander4 reviewed Jan 18, 2026

View reviewed changes

Review findings:

bd233a4

refactored computeSymbolTags - no IsDecl is needed, refactored getSemanticHighlightings - intro map for tags and modifiers,

ratzdi marked this pull request as ready for review January 19, 2026 09:03

ratzdi requested a review from HighCommander4 January 19, 2026 11:39

HighCommander4 requested changes Jan 20, 2026

View reviewed changes

Dimitri Ratz added 2 commits January 20, 2026 14:02

Review findings:

2eb7d3b

- obsolete includes, - public toSymbolTagBitmask, - removed tags from TypeHierarchyItem, - thread_local map in getSemanticHighlightings - minor improvements

Fix format.

3333550

HighCommander4 approved these changes Jan 20, 2026

View reviewed changes

Dimitri Ratz and others added 2 commits January 21, 2026 09:54

Review findings:

49a4a78

- removed obsolete forward-decl and includes - restored include

Merge branch 'main' into users/ratzdi/symbol_tags

1ae72f4

HighCommander4 reviewed Jan 22, 2026

View reviewed changes

Restored include.

585210a

HighCommander4 approved these changes Jan 23, 2026

View reviewed changes

HighCommander4 merged commit c961174 into llvm:main Jan 23, 2026
9 of 10 checks passed



		// Whether T is const in a loose sense - is a variable with this type readonly?
		bool isConst(QualType T);


		const auto SymbolTags = computeSymbolTags(*Decl, R.IsDecl);

		if (SymbolTags & toSymbolTagBitmask(SymbolTag::Deprecated))


		const auto SymbolTags = computeSymbolTags(*Decl);

		static const llvm::DenseMap<SymbolTag, HighlightingModifier>

LSP 3.18 - Symbol Tags #167536

LSP 3.18 - Symbol Tags #167536

Uh oh!

Conversation

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

Uh oh!

Uh oh!

github-actions bot commented Nov 11, 2025

Uh oh!

github-actions bot commented Nov 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ratzdi commented Dec 3, 2025

Uh oh!

HighCommander4 left a comment

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!

HighCommander4 commented Jan 14, 2026

Uh oh!

HighCommander4 left a comment

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!

HighCommander4 Jan 14, 2026 • 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!

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!

ratzdi Jan 16, 2026 • 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!

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!

ratzdi commented Nov 11, 2025 •

edited

Loading

github-actions bot commented Nov 18, 2025 •

edited

Loading

HighCommander4 Jan 14, 2026 •

edited

Loading

ratzdi Jan 16, 2026 •

edited

Loading