On 11/12/18 10:27 AM, Marek Polacek wrote:
This patch implements C++20 P0634R3, Down with typename!
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0634r3.html>
which makes 'typename' optional in several contexts specified in [temp.res].
The gist of the patch is in cp_parser_simple_type_specifier, where, if the
context makes typename optional and the id is qualified, we pretend we've
seen the typename keyword.
Sounds good.
There's quite a lot of churn because we need to be careful where we want
to make typename optional, and e.g. a flag in cp_parser would be too global.
Did you consider adding a cp_parser_flags parameter rather than a
specific bool? I don't feel strongly about it, but it would simplify
things the next time we want to do something like this.
The resolve_typename_type hunk was to make typename9.C work with -fconcepts.
Makes sense.
+ const bool typename_optional_p = (cxx_dialect >= cxx2a);
I'm uncomfortable with repeating this in lots of places in the parser;
I'd prefer to have one place where we control whether the feature is
enabled or not. This seems like the right place:
+ bool typename_p = (flags & CP_PARSER_FLAGS_TYPENAME_OPTIONAL);
+ type = cp_parser_type_name (parser, (qualified_p && typename_p));
I'm not sure about some of the bits in typename5.C, not quite sure if the
code is valid, but I didn't have time to investigate deeply and it seems
pretty obscure anyway. There are preexisting cases when g++ and clang++
disagree.
+ // ??? Not sure if these are (in)valid.
I think these are all valid, since the qualified-ids all appear as a
decl-specifier of a member-declaration.
+ typedef typename A::template N<int> a1;
+ typedef typename A::template N<T> a2;
+ typename A::template N<int> a3;
+ typename A::template N<T> a4;
+ typedef A::N<int> a5; // { dg-error "not a type|invalid" }
+ typedef A::N<T> a6; // { dg-error "not a type|invalid" }
The ::template shouldn't be required here anymore: [temp.names] "In a
qualified-id used as the name in a typename-specifier (12.7),
elaborated-type-specifier (9.1.7.3), using-declaration (9.8), or
class-or-decltype (10.6), an optional keyword template appearing at the
top level is ignored. In these contexts, a < token is always assumed to
introduce a template-argument-list."
This is C++17 DR 1710. You don't need to implement it in this patch,
but let's not test for the wrong behavior. :)
Jason
