Using typeof() together with the :: operator results in a parsing error, though typeof() returns a type-expression where :: is applyable (class type etc.). The message is 'parse error before ";" token' Release: gcc-3.1 Environment: $ uname -a CYGWIN_NT-5.0 OBLOMOW 1.3.10(0.51/3/2) 2002-02-25 11:14 i686 unknown Administrator@OBLOMOW ~ $ gcc -v Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.1/specs Configured with: ../gcc-3.1/configure --program-suffix=-3.1 --enable-shared --enable-threads=win32 --enable-languages=c, c++,objc,f77 --enable-win32-registry : (reconfigured) ../gcc-3.1/configure --prefix=/usr --program-suffix=-3.1 --enable- shared --enable-threads=win32 --enable-languages=c,c++,objc,f77 --enable-win32-registry Thread model: win32 gcc version 3.1 How-To-Repeat: The file attachment 'a.cc' produces the message for line 10.
State-Changed-From-To: open->analyzed State-Changed-Why: Confirmed.
From: Wolfgang Bangerth <bangerth@ices.utexas.edu> To: gcc-gnats@gcc.gnu.org Cc: Subject: Re: c++/6709 Date: Thu, 1 May 2003 15:58:43 -0500 (CDT) A slight variant ICEs with present 3.4 mainline. I opened PR 10586 for this. W. ------------------------------------------------------------------------- Wolfgang Bangerth email: bangerth@ices.utexas.edu www: http://www.ices.utexas.edu/~bangerth/
*** Bug 12379 has been marked as a duplicate of this bug. ***
Just noticed this bug myself. You can work around it by creating a temporary typedef. E.g., typedef typeof(obj) T; T::size_type s; Still annoying though.
The error message is now: tests/pr6709.cc: In function `int main()': tests/pr6709.cc:10: error: `X' in namespace `::' does not name a type which shows what is happening now.
*** Bug 20551 has been marked as a duplicate of this bug. ***
*** Bug 30837 has been marked as a duplicate of this bug. ***
Hmm, I wonder what the current draft of C++0x says of decltype with this respect (right now we reject it).
*** Bug 43285 has been marked as a duplicate of this bug. ***
(In reply to comment #8) > Hmm, I wonder what the current draft of C++0x says of decltype with this > respect (right now we reject it). > In Bug 43285 Comment 1 I said that I think decltype is invalid in this context, which would make this a documentation bug for C++. In the C++0x grammar: simple-type-specifier: ::_opt nested-name-specifier_opt type-name ... decltype ( expression ) nested-name-specifier: type-name :: namespace-name :: nested-name-specifier identifier :: nested-name-specifier template_opt simple-template-id :: type-name: class-name enum-name typedef-name So decltype(expression) cannot appear in a nested-name-specifier
(In reply to comment #4) > Just noticed this bug myself. You can work around it by creating > a temporary typedef. E.g., > > typedef typeof(obj) T; > T::size_type s; > > Still annoying though. This workaround is required for decltype, I don't see why typeof should be any different. The reason is that decltype(obj) doesn't declare a new type-name, it is only a simple-type-specifier, which cannot appear in a nested-name-specifier. The typedef workaround introduces a new type-name, which is allowed in a nested-name-specifier.
the decltype issue is http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#743 the proposed change is in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3031.pdf suspending ...
*** Bug 43780 has been marked as a duplicate of this bug. ***
I had (In reply to comment #14) > *** Bug 43780 has been marked as a duplicate of this bug. *** > The DR 743 has been voted into FCD (CD2) - shouldn't this be unsuspended? thanks!
Unsuspending, DR743 was recently resolved
I have the beginnings of a fix for this (see the patch at http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01392.html); currently there is a bug with my impl where any name on the right of `decltype(x)::' at the front of a nested-name-specifier is considered a non-type unless qualified with typename. I.e. given: struct X { typedef int I; } X x; instead of: decltype(x)::I i = 7; the user must currently write: typename decltype(x)::I i = 7; as if decltype(x) was somehow dependent on a template parameter -- which it obviously isn't as there is no template it sight. Otherwise the patch seems close.
A simple workaround: template <class T> struct TypeEcho { typedef T R; }; #define TYPE_OF(expr) TypeEcho<typeof (*&expr)>::R template <class T> void foo() { typename TYPE_OF(std::vector<T>())::value_type(); } void foo2() { TYPE_OF(std::vector<int>())::value_type(); foo<int>(); }
Author: jason Date: Wed Jul 20 14:21:05 2011 New Revision: 176513 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176513 Log: PR c++/6709 (DR 743) PR c++/42603 (DR 950) gcc/cp/ * parser.c (token_is_decltype, cp_lexer_next_token_is_decltype): New. (cp_parser_nested_name_specifier_opt): Allow decltype. (cp_parser_qualifying_entity): Likewise. (cp_parser_decltype): Replace source tokens with CPP_DECLTYPE. (cp_parser_simple_type_specifier): Handle decltype as scope. (cp_parser_base_specifier): Allow decltype. (cp_parser_base_clause): Don't crash on null base. * parser.h (CPP_KEYWORD, CPP_TEMPLATE_ID): Move to c-common.h. (CPP_NESTED_NAME_SPECIFIER, N_CP_TTYPES): Likewise. gcc/c-family/ * c-common.h (CPP_KEYWORD, CPP_TEMPLATE_ID): Move from cp/parser.h. (CPP_NESTED_NAME_SPECIFIER, N_CP_TTYPES): Likewise. (CPP_DECLTYPE): New. * c-common.c (c_parse_error): Handle CPP_DECLTYPE. Added: trunk/gcc/testsuite/g++.dg/cpp0x/decltype21.C Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/c-family/c-common.h trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/cp/parser.h trunk/gcc/testsuite/ChangeLog
Implemented for 4.7.