[PATCH] D115425: [clangd] Generate ConfigFragment/YAML/docs from one tablegen source

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

In D115425#3190740 <https://reviews.llvm.org/D115425#3190740>, @nridge wrote:

> In D115425#3190698 <https://reviews.llvm.org/D115425#3190698>, @sammccall wrote:
>
>>> there's perhaps a matter of principle where clangd should try to avoid using code patterns (here, non-self-contained files) in its implementation code that it does not support
>>
>> Agree. However the counterargument is putting such patterns in front of our face all the time might encourage us to add some level of support!
>
> Apologies if this is veering off topic (we can continue in a Github Discussion if you'd like), but I got the impression that clangd's lack of support for non-self-contained files was at least partly an opinionated statement that code patterns involving such files are not an important part of modern C++ development.

I think "at least partly" is fair. But this is more a statement of priorities and effort - I think if the feature were free or cheap, everyone would be happy to have it.

(FWIW I do find LLVM's reliance on preprocessor tricks to be not great. Between wanting to fit in with existing infrastructure, and not being able to easily add dependencies, it doesn't seem worth fighting. But this is just another way to say "sure, there are circumstances where it's reasonable to use such patterns")

> If that impression is mistaken, and it's just a matter of no one having gotten around to implementing such support

It's definitely more than implementation, the design needs to solve some hard constraints:

- There needs to be a clear scope and idea of how it'll solve the problems. For instance:
  - does it support files with parse context (e.g. snippets of class bodies like ConfigFragment.inc), or just PP context? If parse context, how is this persisted or recreated? (PCH can't do this today). How does this interact with preambles?
  - how is the file-that-provides-context identified? Is the existing index actually good/available enough for this?
- it needs to not add _too much_ complexity, or at least isolate the complexity to a few places. "Priorities and effort" also means this can't become a maintenance timesink.
- it needs to be useful/powerful enough to justify the complexity that adds. (This ~certainly means it needs to be safe to turn on by default eventually)

I'm not certain it's possible to satisfy all these, but it seems like it might be possible.

> perhaps we could clarify that in https://github.com/clangd/clangd/issues/45 (and maybe put out a "help wanted" / "contributions welcome" announcement somewhere)?

Agreed. I'll post a version of this here.
I'm a little worried that people will expect that if someone makes an honest attempt and gets anywhere then it'll be merged. But I should be less paranoid.
I'm also aware that I & others haven't been a model of working on designs collaboratively in public, we're pretty reliant on getting in a room. So it may be unfair to expect others to do better.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D115425/new/

https://reviews.llvm.org/D115425