In the C language, there's the 2 similar-in-form but distict-in-meaning constructs:
(type)value which is a casting, and (value), which is a grouping.
How do a $LR(1)$ parser deal with this? I can think of a compiler that breaks syntax and semantic boundary able to disambiguate it by providing information about the meaning of the token, but how does a generic parser handle this without high-level information?
It's not possible for an LR(1) parser to solve this problem without using the Lexer Hack: information from the symbol table, which is able to differentiate type names from variable names, is reported to the parser using two different token kinds for "identifier". The impossibility stems from the grammar being otherwise ambiguous, as shown by the example from the linked Wikipedia article, (A)*B, which can be either a cast of a pointer dereference (if A is a type) or a multiplication with redundant grouping parentheses around the first operand (if A is a variable).
The Wikipedia article goes on to claim that Clang does not use the Lexer Hack, although I see this as a technicality: the Clang parser (which is a hand-written, recursive descent parser, not LR(1) table-driven) gets identifier disambiguation information before deciding what to do, but via a separate semantic analysis query instead of using two distinct token kinds. It's the same information, for the same purpose, just delivered via an adjacent channel.
In a comment on another answer, Ben suggests parsing without (at first) fully disambiguating. Due to the aforementioned ambiguity (among others), this is not possible when using an LR(1) parser (you'd get unresolvable shift/reduce conflicts). However, a Generalized LR algorithm can be used instead, which in general yields an abstract syntax forest (which uses node sharing to avoid exponential blowup) rather than a syntax tree. My MS thesis, Elkhound, a Fast, Practical GLR Parser Generator, explored the feasibility of this approach for both C and C++. The resulting parser, called Elsa, could be regarded as a "generic parser [that handles] this without high-level information". (Beware: Elsa is relevant to this question as a proof of concept, but is very much a "fixer upper" for anyone trying to use it to parse real-world C/C++. Clang does that job much better.)
typename that is sometimes necessary in C++ to indicate that the following expression is a type name.
$\endgroup$
typename is related, but a mere mention could imply that's the only additional complication in C++, which isn't the case (see section 5.1 of my thesis for an arguably more impactful issue), and a more thorough treatment is out of scope.
$\endgroup$
They can easily be distinguished by a compiler: In the first case, the thing in parentheses is a type, in the second case it isn’t.
Now if you insist on parsing based on a grammar only, that may be a problem. But there is no reason why a compiler writer would limit themselves in this way. So how does a compiler do it without using high level information? It doesn’t. There is no reason to.
yacc would be nice. Yacc doesn't have semantic-level information, so I thought asking in this regard. I think I'll just check out how other implementations of Yacc break the syntax-semantic barrier.
$\endgroup$
paren_expr for example, and then later a phase with more information decides cast or group. I've used it for programmable precedence/associativity; the parser just recognises a linear chain of terms and operators, turning that into a proper expression happens later.
$\endgroup$