Error-tolerant bracket matching enables our error-tolerant parsing strategies.
The implementation here is *not* yet error tolerant: this patch sets up the APIs
and plumbing, and describes the planned approach.
Details
- Reviewers
hokein - Commits
- rG0360b9f1599b: [pseudo] (trivial) bracket-matching
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
The Bracket struct & translation between token/bracket streams is not really justified by the implementation in this patch.
Next patch will run nontrivial algorithms on the bracket strings.
Happy to scope this patch down (avoid that struct) or up (include the full algorithm) if you prefer, but I think this keeps the diffs clearest.
Thanks, this looks a good start version!
clang-tools-extra/pseudo/include/clang-pseudo/Bracket.h | ||
---|---|---|
10 | brackes => braces | |
clang-tools-extra/pseudo/lib/Bracket.cpp | ||
85 | this is not really parsing, maybe findBrackets? | |
clang-tools-extra/pseudo/unittests/BracketTest.cpp | ||
104 | For this simple case, just using ^ is fine. I think in the near future, we would need more to verify that e.g. which two brackets are paired. And since we're defining some some common functions used by the tests, I wonder what's the plan here (using something like { $1^( $1^)?) |
clang-tools-extra/pseudo/unittests/BracketTest.cpp | ||
---|---|---|
104 |
I thought about the simplest way to specify these tests, and I think the ^ is sufficient. The combination of: The test specifies a) and we check it, and b) and c) can be verified with no extra information. Does this make sense? It's a little implicit, but makes the testcases much more readable than having to specifiy $1^ etc. |
clang-tools-extra/pseudo/unittests/BracketTest.cpp | ||
---|---|---|
104 | Sure, using ^ is sufficient, and agree that make test cases more readable. I was a bit worried about the error-repair cases. For these cases, I thought b) (e.g. we know this { should be paired with the last }, not the next one) is more important, it is probably better explicitly specify in the test, rather than doing it silently. I think we can use trailing comments to explain that while keeping ^. class A ^{ // A void foo() { ^} // A |
clang-tools-extra/pseudo/unittests/BracketTest.cpp | ||
---|---|---|
104 | Added a comment explaining how it's sufficient, and that we should use comments if needed. |
brackes => braces