Nathan Ridge

Here are some notes for getting started with an implementation. Some background on how code completion works in clangd: * The feature's implementation is split across clang's LibSema (semantic analysis...

> Would it be appropiate to add a new `CompletionItemKind` for postfix completions? `CompletionItemKind` is specified in LSP. While extensions to it are possible, they only make sense if the...

> maybe relative: [clangd/vscode-clangd#341](https://github.com/clangd/vscode-clangd/pull/341) Yep, I believe this is the same issue. Should be fixed in vscode-clangd 0.1.20.

I suspect this is #1018

Thanks for filing. This is a very good point which I have noticed as well. I can think of two ways to improve this, which can be pursued independently: 1....

A length threshold sounds reasonable to me. (No reason we can't combine it with other mitigations, `SuppressDefaultTemplateArgs` in particular sounds like an easy win either way.)

Apologies for the delay, I was away for a while. [Here](https://reviews.llvm.org/D108972) is a patch to add a length limit for type hints. I'm also looking into the idea of not...

> Will have to think about how to reconcile this. What I did for now is restrict the use of `PrintCanonicalTypes` to structured bindings only. I don't expect that to...

The two patches mentioned have now been merged. I do plan to work on some further improvements here, so I will leave the issue open. @kadircet, a question about one...

Ah, thanks for the clarification! We already drop name specifiers unconditionally, due to the use of `SuppressScope` [here](https://searchfox.org/llvm/rev/ac312a9d7c03f0be53834d3f295f1971aaf54649/clang-tools-extra/clangd/InlayHints.cpp#33). Perhaps we should relax this, and show name specifiers which are **class...