[clang-tools-extra] Symbol tags in SymbolInformation, WorkspaceSymbol, CallHierarchyItem and TypeHierarchyItem (PR #170103)

via cfe-commits cfe-commits at lists.llvm.org
Fri Apr 17 06:21:07 PDT 2026


================
@@ -22,6 +23,15 @@ namespace clangd {
 
 LLVM_ENABLE_BITMASK_ENUMS_IN_NAMESPACE();
 
+/// A bitmask type representing symbol tags supported by LSP.
+/// \see
+/// https://microsoft.github.io/language-server-protocol/specifications/specification-current/#symbolTag
+using SymbolTags = uint32_t;
----------------
timon-ul wrote:

I think it is fine to keep it like this. That being said, here my problem and thoughts about this setup:

Both types, `SymbolTag` and `SymbolTags` are conceptually **very** connected, but in the code, their connection is very loosely, only with the indirection of the `assert` below this. Preferrably to me if I change the type of `SymbolTag` the type of `SymbolTags` automatically adapts to it, so being a lot less fragile and involving manual changes to `SymbolTags` if we ever get there. Also it would be preferable if in `SymbolTags` you can only represent actual combinations of actual `SymbolTag`s. What I mean is that if I were to shift a bit 31 times it is a valid `uint32_t` and because of that a valid `SymbolTags`, but it does not represent any `SymbolTag`, because we do not have one for every bit. This again feels fragile.

Overall I think this is probably not that problematic, but just from a design perspective I am a bit unhappy about this. I leave it to you if you want to change this (or if a future reviewer wants this). 

https://github.com/llvm/llvm-project/pull/170103


More information about the cfe-commits mailing list