I really don’t see any benefits to the AST approach, only downsides. Storing comments (and whitespace!) in the parser AST is annoying and adds extra maintenance burden. Formatting incomplete code is an important use case when integrated into an IDE. If you want to format macros, you are going to have to build a pseudo-AST anyway, at which point you might as well just use it for all the code in order to avoid duplication. And you really want a “logical line” abstraction in order to properly use the Knuth-esque line breaking algorithm that clang-format
uses.
This is all from experience with the existing pretty printer, which tried to use the AST and never really performed properly. In particular, we had big problems with storing whitespace and comments in the AST: you want to preserve blank lines and such, and you want to place comments in the right place (above or to the right of the things that they’re commenting). The neat thing about clang-format
is that because it formats and handles logical lines immediately, you don’t have to keep that information attached to the AST. This makes things much easier.
Again, I really think everyone in this space should familiarize themselves with clang-format
. They’ve solved the hard problems and from experience with the existing Rust pretty printer there are fundamental design decisions that will bite you in the end if you don’t plan for them early on.