[PATCH] D140462: [clangd] Add schema for `.clangd` config

[Nathan Ridge via Phabricator via cfe-commits]

nridge added a comment.

In D140462#4012996 <https://reviews.llvm.org/D140462#4012996>, @sammccall wrote:

> This has been discussed before, unfortunately while I *thought* it was on a bug, it was actually in a PR: https://github.com/clangd/vscode-clangd/pull/140
>
> I don't think it's a good idea to add a third (arguably, fourth/fifth) place that the config structure and documentation must be maintained by hand, especially one that constrains the structure in non-obvious ways. This needs to be automatically generated.
>
> This implies moving the source of truth to something we can generate {fragment struct, website, parsing code, YAML schema} from.)
>
> I made an attempt at this in https://reviews.llvm.org/D115425 [...]

Thanks for reminding me about the previous work on this! I definitely appreciate the value in generating these various files / pieces of code from a single source of truth.

That said, getting there requires what seems like a non-trivial refactoring that doesn't seem to be in anyone's immediate plans. Meanwhile, it's clear that there is demand in the user community for a schema, and this schema is already out there, today, at https://json.schemastore.org/clangd.json, automatically in effect for anyone who uses VSCode's YAML extension (or comparable functionality in another editor).

The practical implication of allowing the schema to be stored in the clangd repo seems to be:

(1) there is yet another place where the config structure is recorded, but at least that place is in the clangd repo so we're likely to remember to update it at the same time we add new config features

vs.

(2) there is yet another place where the config structure is recorded, but it's on a third-party site and it's probably going to get out of date and only updated when someone periodically remembers to update it, and that person then has to identify and document a batch of changes to the config file format that others have made in the intervening time

Given this choice, I think there's a clear benefit to having the file in the repo.

If/when the described refactoring is implemented, the schema file can start benefiting from also being generated from a single source of truth.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D140462