• [RFC] Markdown support in ASTComment It would be great if the existing ASTComment infrastructure would be extended to support Markdown in Doxygen comments. • The existing ASTComment offers comprehensive structuring of the comment body, with blocks, paragraphs and so on.It would only be natural that we extend this with support for markdown specific elements, like lists and so on.This would best enable consumers to have the full combined structure of the existing parsing, together with the new feature. • This would also better serve other downstream consumers, besides clang-doc itself, versus an approach where markdown support is delegated to another layer or library outside of clang. • Currently, parsing markdown starting from the existing ASTComment structure is awkward:Compiler Explorer Which produces the following AST: Both comments have the same AST structure, even though the first is a one element list, while the second has two elements.The structure doesn’t represent well where line breaks occurred, and one must rely on checking the source locations to be able to determine so. • If one were to avoid this awkwardness by parsing the markdown from the full comment string, then parsing of blocks and paragraphs and so forth would need to be reinvented, if that support is needed in combination. • I’d like to propose we move in the direction of supporting markdown in ASTComment, and proceed to a design that satisfies all stake holders.

Article Summaries:

  • Summary

A proposal has been submitted to extend Clang’s ASTComment infrastructure to natively support Markdown elements such as lists and other formatting. Currently, Markdown is parsed only as plain text, causing identical AST structures for comments that differ in line breaks or list items, and requiring downstream consumers to re‑parse the raw comment string. By integrating Markdown support directly into ASTComment, the full comment structure-including block, paragraph, and list semantics-would be preserved, simplifying use by tools like clang‑doc and other downstream consumers. The proposal references the GSoC 2026 “Improving Clang‑Doc” effort and seeks a design that satisfies all stakeholders.

Sources: