[cfe-dev] [PATCH] C++ nested-name-specifier (Parser)
clattner at apple.com
Sat Aug 9 15:24:14 PDT 2008
On Aug 1, 2008, at 3:43 PM, Eli Friedman wrote:
> On Fri, Aug 1, 2008 at 12:39 PM, Argiris Kirtzidis
> <akyrtzi at gmail.com> wrote:
>> For the next chapter of the C++ support saga, I've implemented
>> nested-name-specifier support ("foo::bar::").
> Hmm, I don't have any low-level comments, but I'm wondering about a
> few things.
> First off, and I guess the most important bit, is how you're planning
> to deal with the C++ cast/declaration ambiguity.
You mean the "most vexing parse" issue? I think that we will have to
do tentative parsing + backtracking for the general case. With luck,
there will be common cases that we can disambiguate early to avoid the
cost of backtracking, but I don't know enough about that area to know
if that will actually be possible in practice.
> This is a more of a side-issue, but would it be worthwhile to make the
> parser keep track of enough information to implement isTypeName
I don't think this is practical unfortunately. In the full generality
of C++, you have to do a ton of semantic analysis to be able to handle
this. For example:
If T is some template, you need to know all about members of T to know
if Y is a variable or type. Also, T could be partially specialized on
int, so you need to handle partial specialization and a bunch of other
stuff to handle this. Pragmatically, I don't think we should worry
about -parse-noop for C++.
Following up with my previous email to Argiris about scoped lookup, my
(again, based on intuition, not the spec) idea of how this would work
is that the parser would call:
... which returns a decl for the template. It would then see the less
than, call an action to determine if the decl is a template or not (if
not, '<' is "operator<"). Assuming it is a template, it would parse
the template args, calling "act on template args" with them. This
would produce a new decl, one for T<int> which Sema would lazily
create if needed and handle partial specialization. The parser would
then see ::Y and then call the "lookup 'y' in decl" action, which
returns yet-another-decl, which is either a type or variable etc.
This doesn't require backtracking or anything crazy in the parser, but
it *does* rely on the actions module to keep a large subset of
information held in the AST just to be able to parse. I don't see a
way around this though.
> It's a relatively large burden on anyone who wants to write
> an Action implementation to be required to keep track of enough
> information to figure out the answer to this question, especially for
Yes it is. In practice, I don't think -parse-noop will work very well
(if at all) for C++. I expect that most clients parsing C++ will end
up using the AST.
More information about the cfe-dev