[Bug c++/26058] New: C++ error recovery regression

[Bug c++/26058] New: C++ error recovery regression

[sabre at nondot dot org]

GCC 3.3 emitted one "parse error before `{' token" error on this code, GCC 4
emits one error for *every* function defined after the error.  It would be nice
to only say "error: a function-definition is not allowed here before '{' token"
once, and perhaps pop up to global scope so that the rest of the file is parsed
in a sane way.

---
int t1() {
  { // unclosed brace
}
int t2() {}
int t3() {}
int t4() {}
int t5() {}
int t6() {}
int t7() {}
int t8() {}
--- 

-Chris


-- 
           Summary: C++ error recovery regression
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: sabre at nondot dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26058

[Bug c++/26058] [3.4/4.0/4.1/4.2 Regression] C++ error recovery regression

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2006-02-01 02:17 -------
Confirmed. 3.4.0 had even worse error messages:
t.cc:4: error: expected primary-expression before "int"
t.cc:4: error: expected `;' before "int"
t.cc:5: error: expected primary-expression before "int"
t.cc:5: error: expected `;' before "int"
t.cc:6: error: expected primary-expression before "int"
t.cc:6: error: expected `;' before "int"
t.cc:7: error: expected primary-expression before "int"
t.cc:7: error: expected `;' before "int"
t.cc:8: error: expected primary-expression before "int"
t.cc:8: error: expected `;' before "int"
t.cc:9: error: expected primary-expression before "int"
t.cc:9: error: expected `;' before "int"
t.cc:10: error: expected primary-expression before "int"
t.cc:10: error: expected `;' before "int"
t.cc:10: error: expected `}' at end of input


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |diagnostic
   Last reconfirmed|0000-00-00 00:00:00         |2006-02-01 02:17:56
               date|                            |
            Summary|C++ error recovery          |[3.4/4.0/4.1/4.2 Regression]
                   |regression                  |C++ error recovery
                   |                            |regression
   Target Milestone|---                         |3.4.6
            Version|unknown                     |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26058

[Bug c++/26058] [3.4/4.0/4.1/4.2 Regression] C++ error recovery regression

[gdr at gcc dot gnu dot org]

------- Comment #2 from gdr at gcc dot gnu dot org  2006-03-01 05:13 -------
Not release cirtical for 3.4.6


-- 

gdr at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.4.6                       |---


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26058

[Bug c++/26058] [3.4/4.0/4.1/4.2 Regression] C++ error recovery regression

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.0.3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26058

[Bug c++/26058] [3.4/4.0/4.1/4.2 Regression] C++ error recovery regression

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.0.3                       |4.0.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26058

[Bug c++/26058] [4.0/4.1/4.2 Regression] C++ error recovery regression

[mmitchel at gcc dot gnu dot org]

------- Comment #3 from mmitchel at gcc dot gnu dot org  2006-05-31 04:54 -------
There is no way to win here.

The EDG front end skips the entire rest of the file:

==
"pr26058.cpp", line 4: error: expected a ";"
    int t2() {}
             ^

At end of source: warning: parsing restarts here after previous syntax error

At end of source: warning: missing return statement at end of non-void
          function "t1"

At end of source: error: expected a "}"
==

That's quieter, but it also means that it issues no error message about the
bogus use of "i" in:

  int t1() {
  { // unclosed brace                                                           
  }
  int t2() {}
  if (i) ;

It's not a good idea to pop back to the top level because function declarations
are perfectly legal in function scope; it's just not legal to have a
definition.

So, the realistic choices are the EDG approach of just skipping to the end of
the current block (which may be the end of the file), or the current behavior. 
I think the current behavior is better.

I've also marked this P5, so that if someone decides to reopen the bug it will
at least be clear that this is not a release-critical problem.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           Priority|P3                          |P5
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26058

[Bug c++/26058] [4.0/4.1/4.2 Regression] C++ error recovery regression

[sabre at nondot dot org]

------- Comment #4 from sabre at nondot dot org  2006-05-31 19:13 -------
I guess I don't follow your logic here.  I agree that the EDG approach is
inferior to the current GCC implementation, but the current GCC approach is
inferior to the old GCC implementation (thus it's a regression, if not a very
important one).  Why does EDG not doing well mean that GCC can't do well?

-Chris


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26058

[Bug c++/26058] [4.0/4.1/4.2 Regression] C++ error recovery regression

[sabre at nondot dot org]

------- Comment #5 from sabre at nondot dot org  2006-05-31 19:14 -------
... Adding mark so that he will hopefully see the previous comment.


-- 

sabre at nondot dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mmitchel at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26058

[Bug c++/26058] [4.0/4.1/4.2 Regression] C++ error recovery regression

[mmitchel at gcc dot gnu dot org]

------- Comment #6 from mmitchel at gcc dot gnu dot org  2006-05-31 19:54 -------
GCC 3.3 isn't really a very good benchmark, since the parser there didn't
handle much of the language.  We'd have to figure out what it actually did for
recovery (how many tokens did it skip, where did it pick things back up), and
then decide if that was a workable strategy.

Fundamentally, though, you only have three options:

1. Skip until you see the end of the block (EDG behavior)

2. Pop to global scope.  Problem: if the user accidentally had a definition in
local scope, but intended the following stuff to be in the local scope, then
you get confused.

3. Stay in local scope (current GCC behavior).  Problem: if the user forgot the
closing brace (and so intended stuff to be in the global scope), then you get
confused.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26058

[Bug c++/26058] [4.0/4.1/4.2 Regression] C++ error recovery regression

[sabre at nondot dot org]

------- Comment #7 from sabre at nondot dot org  2006-05-31 22:17 -------
Ok, makes sense.  The strategy that made sense to me was "If I see a definition
for something that obviously has to be at global scope, but is defined inside
of a function, pop all the way out to global scope and continue, there must be
a missing }".  I have no idea how hard that is to implement though.  If you
think it's infeasible to implement or would confuse some other important case,
then I'm ok with RESOLVED INVALID.

-Chris


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26058

[Bug c++/26058] [4.0/4.1/4.2 Regression] C++ error recovery regression

[mark at codesourcery dot com]

------- Comment #8 from mark at codesourcery dot com  2006-05-31 22:56 -------
Subject: Re:  [4.0/4.1/4.2 Regression] C++ error recovery regression

sabre at nondot dot org wrote:
> ------- Comment #7 from sabre at nondot dot org  2006-05-31 22:17 -------
> Ok, makes sense.  The strategy that made sense to me was "If I see a definition
> for something that obviously has to be at global scope, but is defined inside
> of a function, pop all the way out to global scope and continue, there must be
> a missing }". 

One could attempt that -- but it would be hard.  It would also fall
afoul of code like this:

  void f() {
    void g() {} // Must be at global scope, but I didn't know that.
    g();
  }

which is likely to be another common error mode, since:

  void f() {
    void g();
    g();
  }

is valid.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26058

[Bug c++/26058] [4.0/4.1/4.2 Regression] C++ error recovery regression

[sabre at nondot dot org]

------- Comment #9 from sabre at nondot dot org  2006-05-31 23:00 -------
Right, clearly issuing good diagnostics is a matter of balancing cases against
each other.  While I agree that this is valid:

 void f() {
    void g();
    g();
  }

I don't see it used very often, particularly not in C++ code (I'm accustomed to
seeing it in pre-ansi C code most of the time).  I personally think that
forgetting (or losing track of) the brace occurs more often than the erroneous
version of this, but if you disagree, that's fine and I'll stop bugging you!

-Chris


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26058