[PATCH] D67901: [clangd] Improve semantic highlighting in dependent contexts (fixes #154)

Nathan Ridge via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Oct 3 14:20:15 PDT 2019


nridge marked 2 inline comments as done.
nridge added inline comments.


================
Comment at: clang-tools-extra/clangd/SemanticHighlighting.cpp:219
+  bool VisitDependentNameTypeLoc(DependentNameTypeLoc L) {
+    addToken(L.getNameLoc(), HighlightingKind::DependentType);
+    return true;
----------------
ilya-biryukov wrote:
> nridge wrote:
> > hokein wrote:
> > > nit: we have `kindForType` for hanlding all types, so I'd move the logic of detecting the dependent type there.
> > I did try this, but it doesn't quite work, because `VisitTypeLoc` adds the highlighting to the `TypeLoc`'s `getBeginLoc()`. For something like `typename T::type`, that highlights the `typename` token rather than the `type` token. By contrast, here I add the highlighting to the `DependentNameTypeLoc`'s `getNameLoc()` which will correctly highlight the `type` token.
> You'd want to implement `WalkUpFromDependentNameTypeLoc` instead of `Visit*` to avoid adding extra highlightings in `VisitTypeLoc`.
> 
> In fact, I'm surprised we're not seeing them now.
We're not seeing extra highlightings with the current patch, because `VisitTypeLoc` does not add any highlightings for dependent types (`kindForType()` returns `None` for them). 

So, I don't think there's a problem with using `VisitDependentNameTypeLoc`?


================
Comment at: clang-tools-extra/clangd/SemanticHighlighting.cpp:505
+  case HighlightingKind::DependentType:
+    return "entity.name.type.dependent.cpp";
+  case HighlightingKind::DependentName:
----------------
hokein wrote:
> ilya-biryukov wrote:
> > Maybe have a separate category for all dependent entities instead, i.e. use
> > `entity.name.dependent.type.cpp` and `entity.name.dependent.other.cpp`?
> > 
> > This would allow to specify a single highlighting for both names by stopping at `dependent` subcategory.
> > I'm not sure how this plays into the default colors provided in the editors that support semantic highlighting...
> Having a dedicate dependent entity doesn't align with the existing textmate patterns (the `dependent` type should be under the `entity.name.type` umbrella) --  most highlighters don't have a specific pattern for `dependent`, so we'll fallback to the `entity.name.type` color. If we use `entity.name.dependent.type.cpp`, we'll fall back to `entity.name` color.
+1, I think it's more important that dependent types are highlighted as types out-of-the-box in cases where the theme contains a highlighting for types but not one specifically for dependent types.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67901/new/

https://reviews.llvm.org/D67901





More information about the cfe-commits mailing list