| Re: [cdt-dev] CDT Monthly Call |
Hi Nate,
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.
Thanks for your explanation, what you write seems very reasonable to me.
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.
I agree, this would be very useful. I have some further questions/ideas regarding this topic. As this will be more clang(d) related, I will move this discussion to one of the channels you mentioned in your previous mails.
Hope that helps,
It helps a lot, thanks. It's very nice to have such an active and open community :)
BR, Dominic
Attachment:
smime.p7s
Description: S/MIME cryptographic signature