https://github.com/smcpeak closed
https://github.com/llvm/llvm-project/pull/66436
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
smcpeak wrote:
As the feedback has been mostly negative, I'm closing this PR.
https://github.com/llvm/llvm-project/pull/66436
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
smcpeak wrote:
And more generally, is there a preferred overall approach to documenting AST
structures? My basic idea was to follow the example set by the [The AST
Library](https://clang.llvm.org/docs/InternalsManual.html#the-ast-library) in
the Internals Manual, but expanded to cover
smcpeak wrote:
Is there a different tool and/or style of diagram that would be preferable?
https://github.com/llvm/llvm-project/pull/66436
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
smcpeak wrote:
# On the utility of the diagrams
I'm surprised this is a point of contention. Could someone elaborate on why
the diagrams are troublesome? To me, saying that the diagrams are not useful
is sort of like saying the `-ast-dump` output is not useful. Isn't it better
to be able
smcpeak wrote:
Hi Tom! :)
Indeed, any documentation brings with it an ongoing maintenance burden.
There are two main things I see that need synchronization: the text
descriptions of the fields, and the diagrams.
For the fields, one idea I had is to write a script that runs as part of the