Re: [cdt-dev] CDT Monthly Call

[Nathan Ridge <zeratul976@xxxxxxxxxxx>]

Hi Dominic,

> as discussed in the call today, one point on the roadmap is AST support.
> Clangd provides a protocol extension to get the AST for a text document.
> I just played around with lsp4j and was able to get the AST from clangd*.
>
> Do you have a feeling about if it would be feasible to convert the
> clangd AST to the cdt AST?

My understanding is that the textDocument/ast protocol extension is meant
primarily for visualizing the AST in an "AST view" (which in turn is primarily
useful as a debugging tool for developers of clangd and other clang-based 
tools).

I don't think it's meant for building client-side AST traversal logic on top of,
and I suspect it's likely not detailed enough to build a CDT AST from it.

Moreover, I think the idea behind the Language Server Protocol is to place
operations requiring a semantic understanding of the code like AST
traversal on the server side, and expose them to the client in the form of
high-level operations such as diagnostics and code actions. Among other
advantages, this removes the need for clients to maintain their own AST
representations, which then need to be kept up to date with the evolving
C and C++ languages.

So, I think the more promising approach would be to take the operations
you'd want to perform on the CDT AST (for example, Codan checkers),
and port them to the clang AST instead (for example, in the form of
clang-tidy checkers; note that you'll probably find that the equivalents of
many of CDT's existing Codan checkers already exist, and are more battle-
tested, as clang-tidy checkers), where they can run on the server side as
part of clangd.

One thing that will need to be figured out / improved here is clangd's
extensibility story for third-party checkers and other functionality.
Currently, these need to be baked in at clangd's build time, but a
mechanism to support runtime extensibility seems like it could be a
worthwhile improvement in general.

Hope that helps,
Nate