Now that we're in stage 1 again, I'd like to get your decltype changes
integrated. Sorry I didn't respond sooner.
On 01/20/2011 11:51 AM, Adam Butcher wrote:
The attached patch attempts to resolve bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6709 Allowing
decltype(expr) to appear as the start of a nested-name-specifier.
However there is something wrong. Although it parses fine, the
resulting tree seems to be treated as if it were dependent on a template
parameter. An additional 'typename' prefix is required to get the
desired behaviour.
Although this seems to work for many scenarios, the resulting tree
seems to be treated as dependent (in the sense of dependent on a
template parameter) even when used outside of a template. For
instance:
struct X {};
struct Y { typedef X Inner; enum { E = 7 }; };
Y y;
decltype(y)::Inner x; // error: 'Inner' does not name a type
It's not that it's treated as dependent; the patch to
cp_parser_simple_type parses the nested-name-specifier, then discards it
and doesn't rewind the input stream, so the later call to
cp_parser_nested_name_specifier doesn't see it and it's as though the
"decltype(y)::" didn't exist.
I think you want to arrange to skip the lower calls to
cp_parser_global_scope_opt and cp_parser_nested_name_specifier in this case.
Do you have tests for your decltype patches?
Jason
