[PATCH] D47223: [clangd] Handle enumerators in named, unscoped enums similarly to scoped enums

[Marc-Andre Laperle via Phabricator via cfe-commits]

malaperle added a comment.

In https://reviews.llvm.org/D47223#1109247, @ilya-biryukov wrote:

> I'm not sure if we have tests for that, but I remember that we kept the enumerators in the outer scope so that completion could find them..
>  Am I right that this patch will change the behavior and we won't get enumerators in the following example:
>
>   /// foo.h
>   enum Foo {
>     A, B, C
>   };
>  
>   /// foo.cpp
>   #include "foo.h"
>  
>   int a = ^ // <-- A, B, C should be in completion list here.
>


Not quite but still potentially problematic. With the patch, A, B, C would be found but not ::A, ::B, ::C.

> It's one of those cases where code completion and workspace symbol search seem to want different results :-(
>  I suggest to add an extra string field for containing unscoped enum name, maybe into symbol details? And add a parameter to `Index::fuzzyFind` on whether we need to match enum scopes or not.
>  + at ioeric, + at sammccall,  WDYT?

I'll wait to see what others think before changing it. But I feel it's a bit odd that completion and workspace symbols would be inconsistent. I'd rather have it that A, ::A, and Foo::A work for both completion and workspace. Maybe it would complicate things too much...


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D47223