<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">On 1 Apr 2019, at 14:56, Reid Kleckner via cfe-dev wrote:</p>

</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">Earlier in Clang's life, the parser did not depend on semantic analysis<br>
(lib/Parse did not depend on lib/Sema). However, my understanding is that<br>
as C++ support was added, it became clear that this was awkward, so in<br>
r112244, John removed the virtual 'Action' interface that Sema implemented<br>
and made Parse depend directly on Sema. I wasn't around at the time, so I<br>
don't know the exact motivations, but from what I can tell, clang has<br>
intentionally moved away from the kind of model you are proposing.</p>
</blockquote></div>
<div style="white-space:normal">

<p dir="auto">There are two somewhat-separable subjects here.</p>

<p dir="auto">The first is doing parsing without doing semantic analysis.  C is formally a<br>
context-sensitive grammar, but it is possible to parse a C token sequence<br>
into an ambiguous syntax tree (which would simply contain both valid parses<br>
of e.g. <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">size_t *x;</code> in statement context) without semantic information.<br>
Clang has never been written to do this; the abstraction layer we used to<br>
have between Parser and Sema still had queries like "does this name resolve<br>
to a type" which had to be answered before parsing could continue.  Building<br>
ambiguous parse trees can be useful for source tools but creates a lot of<br>
complexity for a compiler, which has always been Clang's primary mission.</p>

<p dir="auto">The second is how information is exchanged between the parser and<br>
semantic analysis.  Clang's parser used to call its semantic analysis<br>
layer through an abstracted interface, but we never had a useful<br>
alternative implementation, and the sheer breadth of the interactions<br>
required for C++ (just because there are so many new grammatical<br>
productions) made the interface increasingly unwieldy (and hard to<br>
imagine providing an alternative implementation of), so we killed it off.</p>

<p dir="auto">Also, in C there's a massive performance optimization available if you can<br>
combine the lookup performed by the lexer (to check whether something is a<br>
macro and/or a keyword) with the identifier lookups performed by the parser<br>
(in these ambiguous-parse cases) and semantic analysis (for actual name<br>
resolution).  We wouldn't want an abstraction layer to interfere with that<br>
optimization.  (Unfortunately, this optimization loses a lot of its<br>
effectiveness in C++ because there's so much non-lexical lookup of<br>
unqualified names.)</p>

<p dir="auto">John.</p>
</div>
</div>
</body>
</html>