[PATCH] D53191: [clang] Introduce new completion context types

Kadir Cetinkaya via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Oct 24 01:09:00 PDT 2018


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


================
Comment at: include/clang/Sema/CodeCompleteConsumer.h:277
+
+    /// Code completion occurred where an existing name is expected.
+    CCC_ExistingName,
----------------
sammccall wrote:
> It's not obvious what "name" means here, e.g. what distinguishes this from "expression".
> 
> I think the answer is "we want the name of *something*, but we don't know what". I think it's ok to say that explicitly. Or to call this CCC_Symbol, etc.
Renaming to CCC_Symbol


================
Comment at: include/clang/Sema/CodeCompleteConsumer.h:286
+    /// qualified name is permissible.
+    CCC_PotentiallyQualifiedExistingName,
 
----------------
sammccall wrote:
> what distinguishes potentiallyqualifiedexistingname from existingname?
> 
> The one use of ExistingName is the invalid scope case. This seems a) pretty marginal, and b) not to matter to clangd. Does it matter to libclang?
> 
> (The behavior is detectable through the API, but the current behavior doesn't seem that sensible or obviously important)
> 
It kind of matters to libclang, but it is not that important as well. It is used when caching completion items, to decide whether they allow a name specifiers or not. But when I think about the use case, I believe nested name specifiers should be allowed in that context(when scope is invalid, but we still report for global code completion). So seems like it is redundant(not exactly, but currently we have no way of telling it apart due to mentioned fixme).


Repository:
  rC Clang

https://reviews.llvm.org/D53191





More information about the cfe-commits mailing list