[PATCH] D119172: [pseudo] Implement LRGraph

Sam McCall via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Mar 7 06:49:45 PST 2022


sammccall added inline comments.


================
Comment at: clang/include/clang/Tooling/Syntax/Pseudo/LRGraph.h:96
+  uint8_t DotPos = 0;
+  uint8_t RuleLength = 0; // the length of rule body.
+};
----------------
alextsao1999 wrote:
> hokein wrote:
> > alextsao1999 wrote:
> > > Can we add LookaheadSymbol here to implement LR(1)?
> > we could do that. However, we don't have a plan to implement an `LR(1)` yet, we use `SLR(1)`. (though LR(1) is more powerful than SLR(1), the typical deterministic LR(1) parser cannot handle the C++ grammar, we need a "general" parser GLR which can be able to handle arbitrary context-free grammars).
> Thanks for your answering! Oh, I know some `GLR` parsers are based on `LR(1)` or `LALR`, so I think our `GLR` parser is based on `LR(1)` as well. I'm trying to keep up with your train of thought :)
Yeah, GLR changes the tradeoff between more sophisticated and simpler parsers (LR(1) > LALR > SLR(1) > LR(0)).

Normally the sophisticated parsers are able to handle grammars/languages that the simple ones can't, by avoiding action conflicts. So the value is very high.

However with GLR we can handle action conflicts by branching, so the value is "only" avoiding the performance hit of chasing branches that don't go anywhere.

So it didn't really seem worth the extra implementation complexity (or extra size of the in-memory grammar tables!) to use a more powerful parser than SLR(1). Maybe we should even have given LR(0) more thought :-)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119172/new/

https://reviews.llvm.org/D119172



More information about the cfe-commits mailing list