# \[RFC\] A C++ pseudo parser for tooling

**URL:** https://discourse.llvm.org/t/rfc-a-c-pseudo-parser-for-tooling/59217
**Category:** Clang Frontend
**Created:** [November 5, 2021, 1:37pm UTC](https://discourse.llvm.org/t/rfc-a-c-pseudo-parser-for-tooling/59217 "2021-11-05T13:37:11Z")
**Posts on this page:** 1
**Showing post:** 50

<div class="post-metadata">

### Author: ![sam-mccall](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/sam-mccall/32/21_2.png) [@sam-mccall](https://discourse.llvm.org/u/sam-mccall)
#### Post date: [March 8, 2022, 2:02pm UTC](https://discourse.llvm.org/t/rfc-a-c-pseudo-parser-for-tooling/59217/50 "2022-03-08T14:02:59Z")

</div>

Thanks Aaron, we’re going to move the code out of clang and into clang-tools-extra.  
I’m working on a patch with the exact layout, probably `clang-tools-extra/pseudo` with `#include "clang-pseudo/Token.h"` as the public interface, and `clang-pseudo` kept as the name for the standalone tool.

EDIT: review is up: [⚙ D121233 [pseudo] Move pseudoparser from clang to clang-tools-extra](https://reviews.llvm.org/D121233)

> [@AaronBallman](#):
>
> That said, please try to keep build times in mind when working on the pseudo parser as best you can (e.g., be careful/thoughtful about adding tablegen or other dependencies that are known to hurt build times).

Will do. There _is_ likely to be a step where a header needs to be generated from the grammar (to allow code to refer directly to grammar rules). Ensuring that both its dependencies and its includers are minimized should minimize the impact on incremental builds at least. (And no impact on check-clang, which is a benefit we forgot to mention).

---

_[View the full topic](https://discourse.llvm.org/t/rfc-a-c-pseudo-parser-for-tooling/59217)._