[PATCH] D44954: [clangd] Add "member" symbols to the index

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added a comment.

A few questions regarding class members. To pinpoint some interesting cases and agree on how we want those to behave in the long run.

How do we handle template specializations? What will the qualified names of those instantiations be?
I.e. how do I query for `push_back` inside a vector?  Which of the following queries should produce a result?

- `vector::push_back`. Should it match both `vector<T>::push_back` and `vector<bool>::push_back` or only the first one?
- `vector<bool>::push_back`
- `vector<int>::push_back`

What scopes will non-scoped enum members have?
E.g. if I have `enum En { A,B,C}`, which of the following queries will and won't find enumerators?

- `En::A`
- `::A`
- `A`



================
Comment at: clangd/CodeComplete.cpp:932
     Req.Query = Filter->pattern();
+    Req.DeclContexts = {Decl::Kind::Namespace, Decl::Kind::TranslationUnit,
+                        Decl::Kind::LinkageSpec, Decl::Kind::Enum};
----------------
malaperle wrote:
> I want to add a comment here, but I want to make sure I understand why in the first place we were not indexing symbols outside these contexts for the purpose of code completion. Is it because those will be available by Sema code completion anyway?
C++ lookup rules inside classes are way more complicated than in namespaces and we can't possibly hope to give a decent approximation for those.
Moreover, completion inside classes does not require any non-local information, so there does not seem to be a win when using the index anyway.
So we'd rather rely on clang to do completion there, it will give way more useful results than any index implementation.


================
Comment at: clangd/index/Index.h:160
+  /// The Decl::Kind for the context of the symbol, i.e. what contains it.
+  Decl::Kind DeclContextKind;
+  /// Whether or not this is an enumerator inside a scoped enum (C++11).
----------------
How do we use `DeclContextKind`?
Why did we decide to not go with a `bool ForCompletion` instead? (I'm probably missing a conversation in the workspaceSymbol review, could you point me to those instead?)

I'm asking because clang enums are very detailed and designed for use in the compiler, using them in the index seems to complicate things.
It feels we don't need this level of detail in the symbols. Similar to how we don't store the whole structural type, but rely on string representation of completion label instead.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D44954