llvm-project/clang-tools-extra/pseudo
Sam McCall 3132e9cd7c [pseudo] Key guards by RuleID, add guards to literals (and 0).
After this, NUMERIC_CONSTANT and strings should parse only one way.

There are 8 types of literals, and 24 valid (literal, TokenKind) pairs.
This means adding 8 new named guards (or 24, if we want to assert the token).

It seems fairly clear to me at this point that the guard names are unneccesary
indirection: the guards are in fact coupled to the rule signature.

(Also add the zero guard I forgot in the previous patch.)

Differential Revision: https://reviews.llvm.org/D130066
2022-07-21 22:42:31 +02:00
..
benchmarks [pseudo] Implement guard extension. 2022-07-05 15:55:15 +02:00
fuzzer [pseudo] Implement guard extension. 2022-07-05 15:55:15 +02:00
gen [pseudo] Generate an enum type for identifying grammar rules. 2022-07-15 15:09:31 +02:00
include [pseudo] Key guards by RuleID, add guards to literals (and 0). 2022-07-21 22:42:31 +02:00
lib [pseudo] Key guards by RuleID, add guards to literals (and 0). 2022-07-21 22:42:31 +02:00
test [pseudo] Key guards by RuleID, add guards to literals (and 0). 2022-07-21 22:42:31 +02:00
tool [pseudo] Key guards by RuleID, add guards to literals (and 0). 2022-07-21 22:42:31 +02:00
unittests [pseudo] Key guards by RuleID, add guards to literals (and 0). 2022-07-21 22:42:31 +02:00
CMakeLists.txt [pseudo] A basic implementation of compiling cxx grammar at build time. 2022-05-25 11:26:06 +02:00
DesignNotes.md [pseudo] Design notes from discussion today. NFC 2022-05-18 00:08:47 +02:00
README.md Reapply [pseudo] Move pseudoparser from clang to clang-tools-extra" 2022-03-16 01:10:55 +01:00

README.md

clang pseudoparser

This directory implements an approximate heuristic parser for C++, based on the clang lexer, the C++ grammar, and the GLR parsing algorithm.

It parses a file in isolation, without reading its included headers. The result is a strict syntactic tree whose structure follows the C++ grammar. There is no semantic analysis, apart from guesses to disambiguate the parse. Disambiguation can optionally be guided by an AST or a symbol index.

For now, the best reference on intended scope is the design proposal, with further discussion on the RFC.

Dependencies between pseudoparser and clang

Dependencies are limited because they don't make sense, but also to avoid placing a burden on clang mantainers.

The pseudoparser reuses the clang lexer (clangLex and clangBasic libraries) but not the higher-level libraries (Parse, Sema, AST, Frontend...).

When the pseudoparser should be used together with an AST (e.g. to guide disambiguation), this is a separate "bridge" library that depends on both.

Clang does not depend on the pseudoparser at all. If this seems useful in future it should be discussed by RFC.

Parity between pseudoparser and clang

The pseudoparser aims to understand real-world code, and particularly the languages and extensions supported by Clang.

However we don't try to keep these in lockstep: there's no expectation that Clang parser changes are accompanied by pseudoparser changes or vice versa.