[PATCH] D105083: [clangd] Ensure Ref::Container refers to an indexed symbol

Nathan Ridge via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Sun Jul 4 21:33:27 PDT 2021


nridge added inline comments.


================
Comment at: clang-tools-extra/clangd/index/SymbolCollector.cpp:489
     DeclRefs[ND].push_back(
-        SymbolRef{SM.getFileLoc(Loc), Roles, ASTNode.Parent});
+        SymbolRef{SM.getFileLoc(Loc), Roles, getRefContainer(ASTNode.Parent)});
   // Don't continue indexing if this is a mere reference.
----------------
kadircet wrote:
> as mentioned above I think we should start the traversal from `ASTNode.ParentDC`. any downsides to doing that ? I don't see a case where this container we return is **not** a `DeclContext`.
I assume you mean `ASTNode.ContainerDC`.

I tried this suggestion, but it looks like `ContainerDC` does not contain what we want in many cases.

For all of the following cases in `SymbolCollectorTest.RefContainers`:

 * ref2 (variable initializer)
 * ref3 (function parameter default value)
 * ref5 (template parameter default value)
 * ref6 (type of variable)
 * ref7a (return type of function)
 * ref7b (parameter type of function)

`ASTNode.ContainerDC` is the `TranslationUnitDecl` (i.e. the `DeclContext` in which the function or variable is declared) rather than the function or variable itself.

In addition, for ref4 (member initializer), `ContainerDC` is the `RecordDecl` rather than the `FieldDecl`.

So, I don't think this suggestion will work without making the `Ref::Container` field significantly less specific (and thereby the call hierarchy feature less useful in some cases).



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105083



More information about the cfe-commits mailing list