[cfe-dev] decl/expr ambiguity

[Doug Gregor]

On Sun, Aug 24, 2008 at 6:23 PM, Chris Lattner <clattner at apple.com> wrote:
> Okay, here's another crazy idea.  If you boil it down, my objections
> to preparsing are basically:
>
> 3. [minor] the maintenance cost of the second parser.

I'm not at all convinced that this is minor. There's a whole lot of
pre-parsing logic to disambiguate this mess of a declaration:

  ::std::vector<int> v(istream_iterator<int>(fin), typename
lambda<istream_iterator<_1>>::template  apply<T>::type());

I could have had a bit more fun if I used non-type template arguments
in there, since that requires being able to pre-parse expressions. But
the point is that the maintenance issue looks more minor than it is
because Clang isn't parsing the tricky parts of simple-type-specifier
and elaborated-type-specifier.

Having tentative parsing makes other parts of the C++ compiler easier
to implement, especially error recovery where the parser wants to
check whether tweaking the tokens could produce a valid parse. For
example, one GCC recovers well from is the common error of writing a
<: digraph when starting a template argument list, e.g.,

  namespace N { struct X { }; }
  std::vector<::N::X> vec;

There are also places in C++ where we have to determine whether we're
looking at a type or an expression (e.g., in sizeof(blah)). Will we
have another pre-parser for these? Tentatively parsing solves this
problem as well.

All that said, it might not matter so much whether we pre-parse now or
not. As those trickier parsing bits for types go into the parser, they
could probably be abstracted out to be useful for both the
pre-parser(s?) and the parser, to eliminate unnecessary code/coding
duplication.

  - Doug