Re: [wwwdocs] PATCH for Re: new canadian mirror

[Sergey Ivanov]

Hi Gerald,

I see it in the list already :) Thank you!

Sergey

On Sun, Sep 19, 2010 at 10:42 PM, Gerald Pfeifer  wrote:
> On Thu, 16 Sep 2010, Sergey Ivanov wrote:
>> http://gcc.skazkaforyou.com
>>
>> location: Canada
>>
>> Please contact me about this mirror.
>
> Thanks, Sergey!  I am adding this to our mirror list per the patch below.
>
> Gerald
>
>
> Index: mirrors.html
> ===
> RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v
> retrieving revision 1.199
> diff -u -3 -p -r1.199 mirrors.html
> --- mirrors.html        14 Aug 2010 15:43:59 -      1.199
> +++ mirrors.html        19 Sep 2010 20:41:31 -
> @@ -35,6 +35,7 @@ Key fingerprint = 33C2 35A3 4C46 AA3F FB
>  Austria: ftp://gd.tuwien.ac.at/gnu/gcc/";>gd.tuwien.ac.at, 
> thanks to Antonin dot Sprinzl at tuwien dot ac dot at
>  Bulgaria:  href="http://gcc.igor.onlinedirect.bg/";>gcc.igor.onlinedirect.bg, thanks 
> to igor at onlinedirect dot bg
>  Canada:  href="http://gcc.parentinginformed.com";>http://gcc.parentinginformed.com, 
> thanks to James Miller (jmiller at parentinginformed dot com).
> +Canada:  href="http://gcc.skazkaforyou.com";>http://gcc.skazkaforyou.com, thanks to 
> Sergey Ivanov (mirrors at skazkaforyou dot com)
>  China:  href="ftp://linuxforum.net/ftp.gcc.gnu.org/";>ftp://linuxforum.net/ftp.gcc.gnu.org/,
>  thanks to David Deng (david99deng at yahoo dot com)
>  France (no snapshots):  href="ftp://ftp.lip6.fr/pub/gcc/";>ftp.lip6.fr, thanks to ftpmaint at lip6 
> dot fr
>  France, Brittany:  href="ftp://ftp.irisa.fr/pub/mirrors/gcc.gnu.org/gcc/";>ftp.irisa.fr, 
> thanks to ftpmaint at irisa dot fr
>

RE: Range-based for in c++98

[Rodrigo Rivas]

> This is quite unreadable and not very informative.
Totally agree.

> Here there are two problems...
> snipped

I think that you are taking the wrong approach: you call
"cp_parser_range_for" with C++98 and then if such a loop is parsed
(the ':') you issue an error.
Maybe you should try to add the check to the "cp_parser_c_for" function.
Note that a range-based for always have a declaration in the first
sub-statement, so next the "cp_parser_c_for" will expect a ';' or a
initialization ('(', '=' or '{', IIRC).
If instead of that, a ':' is found there is your chance to diagnose!

Regards.
Rodrigo

[C++0x] implementing forward declarations for enums

[Rodrigo Rivas]

Hello all.

This patch tries to implement the C++0x featue "Forward declarations
for enums" aka "opaque enum declarations":
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2764.pdf

Please note that this is a WIP, and as such lacks formatting,
comments, testcases, etc.

Except for the things noted below, I think it works pretty well.

TODOs
1
A enum declaration should fail if adds a list of constants and it
already have one. I check it with "TYPE_VALUES (type)", but this is
incorrect because an empty list will not be seen.
So, the current patch will accept incorrect code like:
enum class Foo { };
enum class Foo { A, B, C};
I think that a new flag is needed for ENUMERAL_TYPE, but I don't know which one.

2
I am calling "finish_enum" several types, for each of the opaque
declarations until it gets a list of constants. It doesn't seem to
cause problems except with the debug information. With default flags
and everything, gdb sees only the first declaration:
enum class Foo;
enum class Foo {A, B, C}
Foo f;

(gdb) ptype f;
enum Foo {}

I don't see an easy way to solve it...

3
I don't like very much the added parameter to the "start_enum"
function, but I don't see how to do it without breaking existing code.

Comments are most welcomed.

Regards.
Rodrigo
Index: gcc/cp/decl.c
===
--- gcc/cp/decl.c   (revision 164424)
+++ gcc/cp/decl.c   (working copy)
@@ -11321,27 +11321,48 @@ xref_basetypes (tree ref, tree base_list)
may be used to declare the individual values as they are read.  */
 
 tree
-start_enum (tree name, tree underlying_type, bool scoped_enum_p)
+start_enum (tree name, tree enumtype, tree underlying_type, bool scoped_enum_p)
 {
-  tree enumtype;
-
   gcc_assert (TREE_CODE (name) == IDENTIFIER_NODE);
 
+  /* [C++0x dcl.enum]p5: 
+
+If not explicitly specified, the underlying type of a scoped
+enumeration type is int.  */
+  if (!underlying_type && scoped_enum_p)
+underlying_type = integer_type_node;
+
   /* If this is the real definition for a previous forward reference,
  fill in the contents in the same object that used to be the
  forward reference.  */
-
-  enumtype = lookup_and_check_tag (enum_type, name,
-  /*tag_scope=*/ts_current,
-  /*template_header_p=*/false);
-
+  if (!enumtype)
+enumtype = lookup_and_check_tag (enum_type, name,
+/*tag_scope=*/ts_current,
+/*template_header_p=*/false);
   if (enumtype != NULL_TREE && TREE_CODE (enumtype) == ENUMERAL_TYPE)
 {
-  error_at (input_location, "multiple definition of %q#T", enumtype);
-  error_at (DECL_SOURCE_LOCATION (TYPE_MAIN_DECL (enumtype)),
-   "previous definition here");
-  /* Clear out TYPE_VALUES, and start again.  */
-  TYPE_VALUES (enumtype) = NULL_TREE;
+  if (scoped_enum_p != SCOPED_ENUM_P (enumtype))
+   {
+ error_at (input_location, "scoped/unscoped mismatch in enum %q#T", 
enumtype);
+ error_at (DECL_SOURCE_LOCATION (TYPE_MAIN_DECL (enumtype)),
+   "previous definition here");
+   }
+  if (!underlying_type
+ || !same_type_p (underlying_type, ENUM_UNDERLYING_TYPE (enumtype)))
+   {
+ error_at (input_location, "different underlying type in enum %q#T", 
enumtype);
+ error_at (DECL_SOURCE_LOCATION (TYPE_MAIN_DECL (enumtype)),
+   "previous definition here");
+   }
+
+  if (cxx_dialect == cxx98)
+   {
+ error_at (input_location, "multiple definition of %q#T", enumtype);
+ error_at (DECL_SOURCE_LOCATION (TYPE_MAIN_DECL (enumtype)),
+   "previous definition here");
+ /* Clear out TYPE_VALUES, and start again.  */
+ TYPE_VALUES (enumtype) = NULL_TREE;
+   }
 }
   else
 {
@@ -11357,19 +11378,10 @@ tree
   if (enumtype == error_mark_node)
 return enumtype;
 
+  SET_SCOPED_ENUM_P (enumtype, scoped_enum_p);
   if (scoped_enum_p)
-{
-  SET_SCOPED_ENUM_P (enumtype, 1);
-  begin_scope (sk_scoped_enum, enumtype);
+begin_scope (sk_scoped_enum, enumtype);
 
-  /* [C++0x dcl.enum]p5: 
-
-  If not explicitly specified, the underlying type of a scoped
-  enumeration type is int.  */
-  if (!underlying_type)
-underlying_type = integer_type_node;
-}
-
   if (underlying_type)
 {
   if (CP_INTEGRAL_TYPE_P (underlying_type))
Index: gcc/cp/pt.c
===
--- gcc/cp/pt.c (revision 164424)
+++ gcc/cp/pt.c (working copy)
@@ -6654,7 +6654,7 @@ lookup_template_class (tree d1,
  if (!is_dependent_type)
{
  set_current_access_from_decl (TYPE_NAME (template_type));
- t = start_enum (TYPE_IDENTIFIER (template_type),
+ t = start_enum (TYPE_IDENTIFIER (template_

Re: [C++-0x] User-defined literals.

[Rodrigo Rivas]

> I'm looking at (besides input on what I've got currently):
So far I see it fine... except:
int len = TREE_STRING_LENGTH (strl);
should be:
int len = TREE_STRING_LENGTH (strl) - 1;
since the draft says "its length excluding the terminating null character".

Also, I had to change:
identifier = perform_koenig_lookup (identifier, vec,
/*include_std=*/false);
into:
identifier = lookup_function_nonclass (identifier, vec,
/*block_p*/0);
to make it work. The issue here is that "perform_koenig_lookup" does
not work with built-in types, since they don't have associated
namespaces, I guess. Not sure about the block_p parameter, however.

> 1. A warning or error if a user chooses a suffix that gcc uses.  I was
> surprised that 'w', 'q', 'i', 'j' and several others were used by gcc for
> floats.  I won't be the only one.  The standard is clear that
> implementations get first crack at these but it shouldn't be a mystery or a
> surprise when things don't work as expected.
Agreed.

> 2. Should we at least pedwarn about user not starting a suffix with an
> underscore?  Probably.  Non-underscore suffixen are reserved to the
> implementation but I think a user should be able to use one if it's not used
> by gcc though the user risks non-portability and potential but unlikely
> future breakage.
Hmmm, I don't think so. Reserved but unused identifiers are not warned
about anywhere, AFAIK.
For example, I type:
   int __x, _Y;
and no warning at all.
Sure it would be pedanticly nice to have such a warning, but it would
be another topic.

> 3. The big one: Getting the integer(long long) and float(long double)
> suffixes that are not used by gcc out of the preprocessor.  Then we can
> build the calls.
Oh, I see the problem...

> 4.  If, for long long and long double the usual signature is not found,
> first look for a: _suffix(char*) and failing that: template
> _suffix().  So we'll need to make the lookup of these two signatures more
> complex.
Yes, the problem here is that we don't have to use the usual overload
resolution, but check the results of the lookup by hand.
I guess that it won't be so easy...

Regards.
Rodrigo

Re: End of GCC 4.6 Stage 1: October 27, 2010

[NightStrike]

On Mon, Sep 6, 2010 at 1:32 PM, NightStrike  wrote:
> On Mon, Sep 6, 2010 at 1:24 PM, Andrew Haley  wrote:
>> On 09/06/2010 06:18 PM, NightStrike wrote:
>>> On Mon, Sep 6, 2010 at 12:21 PM, Richard Guenther
>>>  wrote:
 On Mon, Sep 6, 2010 at 6:19 PM, NightStrike  wrote:
> On Mon, Sep 6, 2010 at 5:21 AM, Richard Guenther  
> wrote:
>> On Mon, 6 Sep 2010, Tobias Burnus wrote:
>>
>>> Gerald Pfeifer wrote:
 Do you have a pointer to testresults you'd like us to use for 
 reference?

  From our release criteria, for secondary platforms we have:

    • The compiler bootstraps successfully, and the C++ runtime library
      builds.
    • The DejaGNU testsuite has been run, and a substantial majority of 
 the
      tests pass.
>>>
>>> See for instance:
>>>   http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg00295.html
>>
>> There are no libstdc++ results in that.
>>
>> Richard.
>
> This is true.  I always run make check-gcc.  What should I be doing 
> instead?

 make -k check

>>>
>>> Ugh.  And I thought I was golden :)
>>>
>>> This apparently requires autogen to do something about
>>> fixincludes/check.tpl.  I have no idea what that is or what that
>>> means
>>
>> Just ignore the fixincludes test results.
>>
>> Andrew.
>>
>
> Thanks!  Life just got easier again :)
>
> Running it with -j5.  Hopefully cygwin doesn't barf on that.. I know
> cygwin used to have issues with -j.
>

Ok, so it took a while to eventually find out that cygwin still
malfunctions with -j, and I get lots of "fork() blows because it can't
figure out how to find ubiquitous resources" errors.  However, I
eventually got this to finish:

http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg01864.html

So there's a complete testsuite that includes libstdc++ this time.  I
will now have this running continuously.

Note that you won't see results every day -- it takes a LONG time to
do this, mostly because I can't do -j on cygwin.  I imagine results
will be every 4 days or so if I run continuously.

Is this enough now for us to qualify?

RE: Range-based for in c++98

[Magnus Fromreide]

On Mon, 2010-09-20 at 10:39 +0200, Rodrigo Rivas wrote:
> > This is quite unreadable and not very informative.
> Totally agree.
> 
> > Here there are two problems...
> > snipped
> 
> I think that you are taking the wrong approach: you call
> "cp_parser_range_for" with C++98 and then if such a loop is parsed
> (the ':') you issue an error.
> Maybe you should try to add the check to the "cp_parser_c_for" function.
> Note that a range-based for always have a declaration in the first
> sub-statement, so next the "cp_parser_c_for" will expect a ';' or a
> initialization ('(', '=' or '{', IIRC).
> If instead of that, a ':' is found there is your chance to diagnose!

Well, yes, this is true but there is still the issue that

void f() {
for(class C{};;)
  ;
}

generates the message

error: types may not be defined in range-based for loops

when compiled with -std=c++0x and no patches and that is odd since this
loop isn't range-based.

/MF

RE: Range-based for in c++98

[Rodrigo]

> Well, yes, this is true but there is still the issue that
> 
> void f() {
> for(class C{};;)
>   ;
> }
> 
> generates the message
> 
> error: types may not be defined in range-based for loops
> 
> when compiled with -std=c++0x and no patches and that is odd since this
> loop isn't range-based.
Oh, I see...
The problem is that regular C for loops allows defining types in the
first statement, whereas range-based for loops do not. That, if I'm
reading the draft correctly.

So the problem is that when setting the
type_definition_forbidden_message to non-NULL, when it sees the type it
calls error() instead of cp_parser_error() so the
cp_parser_parse_tentatively has no effect.

The easy solution would be to remove the assignment to
type_definition_forbidden_message and then check for this case
particulary.
Or we can change the cp_parser_check_type_definition() function to call
cp_parser_error() instead of error().

Or we can just accept the type definition in the range-for and hope that
nobody will notice :P

Regards.
Rodrigo

Re: End of GCC 4.6 Stage 1: October 27, 2010

[Jonathan Wakely]

On 20 September 2010 17:33, NightStrike wrote:
>
> Ok, so it took a while to eventually find out that cygwin still
> malfunctions with -j, and I get lots of "fork() blows because it can't
> figure out how to find ubiquitous resources" errors.  However, I
> eventually got this to finish:
>
> http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg01864.html
>
> So there's a complete testsuite that includes libstdc++ this time.  I
> will now have this running continuously.
>
> Note that you won't see results every day -- it takes a LONG time to
> do this, mostly because I can't do -j on cygwin.  I imagine results
> will be every 4 days or so if I run continuously.
>
> Is this enough now for us to qualify?

Could you send me your libstdc++.log file?
I'm curious about some of the libstdc++ failures, which are in pretty
simple tests that shouldn't be target dependent.  There might be
something simple in testsuite_hooks.h or another common file that
causes all those failures.

Re: Range-based for in c++98

[Rodrigo Rivas]

On second reading of the C++0x draft in cannot find any reason of what
the new type in range-fors should not be allowed.

Maybe someone can read it differently?

Regard.
Rodrigo

Re: Range-based for in c++98

[Manuel López-Ibáñez]

On 20 September 2010 20:19, Rodrigo  wrote:
>> Well, yes, this is true but there is still the issue that
>>
>> void f() {
>> for(class C{};;)
>>   ;
>> }
>>
>> generates the message
>>
>> error: types may not be defined in range-based for loops
>>
>> when compiled with -std=c++0x and no patches and that is odd since this
>> loop isn't range-based.
> Oh, I see...
> The problem is that regular C for loops allows defining types in the
> first statement, whereas range-based for loops do not. That, if I'm
> reading the draft correctly.
>
> So the problem is that when setting the
> type_definition_forbidden_message to non-NULL, when it sees the type it
> calls error() instead of cp_parser_error() so the
> cp_parser_parse_tentatively has no effect.
>
> The easy solution would be to remove the assignment to
> type_definition_forbidden_message and then check for this case
> particulary.

cp_parser_type_specifier_seq could return some indication of why the
parsing has failed or whether it has parsed a declaration. This is
much more useful than just throwing an error. In general this is true
of the whole C++ parser.

> Or we can change the cp_parser_check_type_definition() function to call
> cp_parser_error() instead of error().

No please, cp_parser_error() is almost always annoying and
uninformative saying things like:

expected __asm__ before ';'

because it lacks context.

> Or we can just accept the type definition in the range-for and hope that
> nobody will notice :P

You will have to diagnose it with -pedantic anyway.

>
> Regards.
> Rodrigo
>
>

GCC Bugzilla upgrade to version 3.6.2 ready

[Frédéric Buclin]

Hi all,

I'm done with the implementation of customizations for the 3.6.2
Bugzilla installation. The test installation, which is based on a copy
of the GCC Bugzilla database (snapshot taken on September 9), is live at
http://gcc.gnu.org/bugzilla-test/.

Please test it, and file bugs related to missing or broken
customizations in the new "Bugzilla" product on the test installation,
i.e. using this link:
http://gcc.gnu.org/bugzilla-test/enter_bug.cgi?product=Bugzilla

I prefer you to report bugs *before* the upgrade, not after. If
something broken is found after the upgrade, don't complain. :)

If nothing severe is found in the coming days, we will probably upgrade
the production installation later this week. I think Ian will keep you
informed about this.


Have fun testing the new Bugzilla,

LpSolit

RE: [C++0x] implementing forward declarations for enums

[Hargett, Matt]

I just wanted to say thanks for implementing this.

Being able to forward declare enums will make dependency breaking in legacy 
code much easier in many real-world cases. 

Thanks again!

-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Rodrigo 
Rivas
Sent: Monday, September 20, 2010 6:58 AM
To: gcc@gcc.gnu.org
Subject: [C++0x] implementing forward declarations for enums

Hello all.

This patch tries to implement the C++0x featue "Forward declarations for enums" 
aka "opaque enum declarations":
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2764.pdf

Please note that this is a WIP, and as such lacks formatting, comments, 
testcases, etc.

Except for the things noted below, I think it works pretty well.

TODOs
1
A enum declaration should fail if adds a list of constants and it already have 
one. I check it with "TYPE_VALUES (type)", but this is incorrect because an 
empty list will not be seen.
So, the current patch will accept incorrect code like:
enum class Foo { };
enum class Foo { A, B, C};
I think that a new flag is needed for ENUMERAL_TYPE, but I don't know which one.

2
I am calling "finish_enum" several types, for each of the opaque declarations 
until it gets a list of constants. It doesn't seem to cause problems except 
with the debug information. With default flags and everything, gdb sees only 
the first declaration:
enum class Foo;
enum class Foo {A, B, C}
Foo f;

(gdb) ptype f;
enum Foo {}

I don't see an easy way to solve it...

3
I don't like very much the added parameter to the "start_enum"
function, but I don't see how to do it without breaking existing code.

Comments are most welcomed.

Regards.
Rodrigo

Re: Range-based for in c++98

[Rodrigo Rivas]

>> The easy solution would be to remove the assignment to
>> type_definition_forbidden_message and then check for this case
>> particulary.
>
> cp_parser_type_specifier_seq could return some indication of why the
> parsing has failed or whether it has parsed a declaration. This is
> much more useful than just throwing an error. In general this is true
> of the whole C++ parser.
You are right. Being a C++ parser it would be appropriate to implement
some kind of exception-like error management.
But this is way out of my scope (pun intended).

>> Or we can change the cp_parser_check_type_definition() function to call
>> cp_parser_error() instead of error().
>
> No please, cp_parser_error() is almost always annoying and
> uninformative saying things like:
>
> expected __asm__ before ';'
>
> because it lacks context.
I said that just because of c_parser_error respect the tentative flag.
I think that you can put whatever message you like, can't you?

>
>> Or we can just accept the type definition in the range-for and hope that
>> nobody will notice :P
>
> You will have to diagnose it with -pedantic anyway.
Are you sure? As I said in other post, I am no longer sure that the
C++0x draft forbids the type definition in this context.
But I'm no expert in standarese, so I'm still undecided.

Re: GCC Bugzilla upgrade to version 3.6.2 ready

[Jonathan Wakely]

2010/9/20 Frédéric Buclin:
>
> Have fun testing the new Bugzilla,

Oops, I didn't realise that changes to the test installation get
emailed to gcc-bugs and to the users who reported the bug or are CC'd
on it, but that raised a couple of possible bugs.

I've filed http://gcc.gnu.org/bugzilla-test/show_bug.cgi?id=45650 and
http://gcc.gnu.org/bugzilla-test/show_bug.cgi?id=45651

Re: GCC Bugzilla upgrade to version 3.6.2 ready

[Frédéric Buclin]

Le 21. 09. 10 01:18, Jonathan Wakely a écrit :
> Oops, I didn't realise that changes to the test installation get
> emailed to gcc-bugs and to the users who reported the bug or are CC'd
> on it

Yeah, it's a production-ready installation, with all features enabled.
:) Only bugs filed in the Bugzilla product are not emailed to the GCC
mailing-list. I could create a "Test" product, if you want to.

LpSolit

Re: End of GCC 4.6 Stage 1: October 27, 2010

[NightStrike]

On Mon, Sep 20, 2010 at 2:22 PM, Jonathan Wakely  wrote:
> On 20 September 2010 17:33, NightStrike wrote:
>>
>> Ok, so it took a while to eventually find out that cygwin still
>> malfunctions with -j, and I get lots of "fork() blows because it can't
>> figure out how to find ubiquitous resources" errors.  However, I
>> eventually got this to finish:
>>
>> http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg01864.html
>>
>> So there's a complete testsuite that includes libstdc++ this time.  I
>> will now have this running continuously.
>>
>> Note that you won't see results every day -- it takes a LONG time to
>> do this, mostly because I can't do -j on cygwin.  I imagine results
>> will be every 4 days or so if I run continuously.
>>
>> Is this enough now for us to qualify?
>
> Could you send me your libstdc++.log file?
> I'm curious about some of the libstdc++ failures, which are in pretty
> simple tests that shouldn't be target dependent.  There might be
> something simple in testsuite_hooks.h or another common file that
> causes all those failures.
>

I already killed that build, so I'll have to do it on the next one.
The toolchain is broken once again here:

x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I../../../build/mingw/mingw-w64-crt
 -m32 -I../../../build/mingw/mingw-w64-crt/include -D_CRTBLD -I/tmp/build/root/x
86_64-w64-mingw32/include   -pipe -std=gnu99 -Wall -Wextra -Wformat -Wstrict-ali
asing -Wshadow -Wpacked -Winline -Wimplicit-function-declaration -Wmissing-noret
urn -Wmissing-prototypes -g -O2 -MT math/lib32_libmingwex_a-sf_erf.o -MD -MP -MF
 math/.deps/lib32_libmingwex_a-sf_erf.Tpo -c -o math/lib32_libmingwex_a-sf_erf.o
 `test -f 'math/sf_erf.c' || echo '../../../build/mingw/mingw-w64-crt/'`math/sf_
erf.c
../../../build/mingw/mingw-w64-crt/math/sf_erf.c: In function `__trunc_float_wor
d.isra.0':
../../../build/mingw/mingw-w64-crt/math/sf_erf.c:268:1: internal compiler error:
 tree check: expected var_decl, have debug_expr_decl in const_value_known_p, at
varpool.c:375
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [math/lib32_libmingwex_a-sf_erf.o] Error 1
make[2]: Leaving directory `/tmp/build/mingw/obj'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/tmp/build/mingw/obj'
make: *** [build/mingw/obj/.compile.marker] Error 2


so it'll have to wait :( :(

Re: Range-based for in c++98

[Manuel López-Ibáñez]

On 21 September 2010 01:06, Rodrigo Rivas  wrote:
>>> The easy solution would be to remove the assignment to
>>> type_definition_forbidden_message and then check for this case
>>> particulary.
>>
>> cp_parser_type_specifier_seq could return some indication of why the
>> parsing has failed or whether it has parsed a declaration. This is
>> much more useful than just throwing an error. In general this is true
>> of the whole C++ parser.
> You are right. Being a C++ parser it would be appropriate to implement
> some kind of exception-like error management.

You do not need exceptions to implement what I said, just to return a
value. A boolean would suffice to detect whether you parsed a
definition.

> But this is way out of my scope (pun intended).
>
>>> Or we can change the cp_parser_check_type_definition() function to call
>>> cp_parser_error() instead of error().
>>
>> No please, cp_parser_error() is almost always annoying and
>> uninformative saying things like:
>>
>> expected __asm__ before ';'
>>
>> because it lacks context.
> I said that just because of c_parser_error respect the tentative flag.
> I think that you can put whatever message you like, can't you?

The "before whatever" is hardcoded. And tentative parsing is
thoroughly abused in the parser. It means that you can get an error
but you do not really know what happened, so you ignore it and try
something else, which is bad in many (most?) cases. Most fixes I have
done to the C++ parser error-handling involved removing tentative
parsing.

Cheers,

Manuel.