Sam McCall

> How does vscode handle this? You work on coc-clangd and vscode-clangd, so I assume it is the temp file solution you suggested? VSCode lets you connect server output to...

Today I got a message on startup: `LSP client log is large (1121 MB): /usr/local/google/home/sammccall/.cache/nvim/lsp.log` The alert is nice, but having this file accumulate logs from all sessions forever means...

> Apart from that we're not actively working on a solution here ATM. We've had multiple reports of this. I think we would accept a patch that allowed overriding the...

AFAICS the error here is correct. The implementation header would be standalone if it had header guards, is there a reason you can't add them? (Clangd doesn't support non-standalone files:...

> But the include is guarded, which means the implementation file will only be seen once since we can only see the main header once. This is true if the...

> Oh, now it makes a lot of sense in my head. So the issue is that we start from the file we opened, and I guess it processes it...

So there are three issues here: 1. header guards are required because we only support self-contained files (#45) 2. conventional `#ifndef` guards on the main-file aren't recognized because the preamble...

As you say, we don't have enough information in clangd to fix this, we need to fix this in clang's SemaCodeComplete. Unfortunately these "definition completions" seem to be an accidental...

I relanded the fix from that bug but it still feels sluggish. ``` #include std::pair hack_clangd[1

We support the inverse: `// IWYU pragma: private; include "foo.h"`. Is it possible to use that instead? The `export` pragma is a bit unfortunately designed: when the parser sees a...