Nathan Ridge

> With #1142 fixed, the diagnostics about unrecognized arguments could be suppressed using https://clangd.llvm.org/config.html#suppress. I guess suppressing the error is not helpful in this case, because "Couldn't build compiler instance"...

Clangd uses the macro expansion to determine the context in which to perform completion. Consider: ```c++ #include struct MyClass { void foo(); void bar(); }; #define STD(x) std::x #define MYCLASS(x)...

> Editors usually have some sort of non-semantic fallback (e.g. vscode's `editor.wordBasedSuggestions`) that will offer all the words from the document, which is usually no worse than clangd could do...

I suppose clangd could also heuristically choose a context as a fallback, e.g. the macro invocation context (i.e. offer the same completions at `MACRO(x^` as if just `x^` had been...

> That would be a huge improvement in my case, where the "non-working" macro is `BOOST_TEST` and normally clangd is perfectly capable of completing the expression if I type it...

Thanks for filing. > I don't know if this is a bug in clangd itself or the VSCode extension. The relevant logic is in clangd, so I transferred the issue.

@tom-anders agreed, the dependent type check seems unnecessary; `T` might instantiate to something const or something mutable, but `T const` will always be const.

Thanks for the fix!

The issue seems to be unrelated to the presence of the explicit instantiations -- I see the same (inconsistent) completion behaviour without them.

Here's a further reduced testcase: ```c++ template concept X = requires(T t) { t.xxx; }; template struct A { void foo(T); }; template void A::foo(T t) { t.^ }; ```...