[Bug c++/22590] New: parser hosed

[Bug c++/22590] New: parser hosed

[igodard at pacbell dot net]

Parser seems totally lost

-- 
           Summary: parser hosed
           Product: gcc
           Version: 3.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: igodard at pacbell dot net
                CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/22590] parser hosed

[igodard at pacbell dot net]

------- Additional Comments From igodard at pacbell dot net  2005-07-21 14:31 -------
Created an attachment (id=9319)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9319&action=view)
compiler output


-- 


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

[Bug c++/22590] parser hosed

[igodard at pacbell dot net]

------- Additional Comments From igodard at pacbell dot net  2005-07-21 14:32 -------
Created an attachment (id=9320)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9320&action=view)
source code (compressed)


-- 


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

[Bug c++/22590] parser hosed

[igodard at pacbell dot net]

------- Additional Comments From igodard at pacbell dot net  2005-07-21 14:49 -------
The actual problem is a missing "#" on a #include statement, so the code is
invalid. But the error is reported not where that occurs but deep inside the
next included file. So this report is actually a complaint about the file
position reported in the diagnostic.

-- 


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

[Bug c++/22590] parser hosed

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #9319|application/octet-stream    |text/plain
          mime type|                            |


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

[Bug c++/22590] parser does not recover well after error

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-21 17:58 -------
Confirmed.
Testcase:
include "core.hh"
typedef unsigned int size_t;
namespace std
{
  using ::size_t;
}

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
           Keywords|                            |diagnostic
   Last reconfirmed|0000-00-00 00:00:00         |2005-07-21 17:58:28
               date|                            |
            Summary|parser hosed                |parser does not recover well
                   |                            |after error


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

[Bug c++/22590] parser does not recover well after error

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2005-07-21 23:11 -------
With Andrew's little testcase, I get 
 
g/x> cat > x.cc 
include "core.hh" 
typedef unsigned int size_t; 
namespace std 
{ 
  using ::size_t; 
} 
 
g/x> /home/bangerth/bin/gcc-4.1-pre/bin/c++ -c x.cc 
x.cc:1: error: expected constructor, destructor, or type conversion before 
string constant 
x.cc:5: error: ‘::size_t‘ has not been declared 
 
I guess that's as good as it gets: it doesn't understand your include 
statement 
(understandably so) and then keeps reading. Since there is no semicolon 
after the botched include, it skips the rest of the presumed statement 
until after your declaration of ::size_t. The next error is where you 
use ::size_t, which of course it doesn't know. 
 
What's wrong with this?  
 
W. 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


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

[Bug c++/22590] parser does not recover well after error

[igodard at pacbell dot net]

------- Additional Comments From igodard at pacbell dot net  2005-07-22 01:25 -------
Then Andrew's test case is not showing the problem. In the original, although
the message is the same as Andrew's, the line/file reference is deep inside a
system include that contains the first program text after the point of error:

In file included from
/mnt/export/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.0/../../../../include/c++/3.4.0/cstddef:48,
                 from /home/ivan/ootbc/common/include/comtype.hh:6,
                 from ../../members/include/opClock.hh:4,
                 from opClock.cc:2:
/mnt/export/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.0/include/stddef.h:151:
error: expected constructor, destructor, or type conversion before string constant 

The cited line in stddef.h does not contain a string constant, as the message
seems to assert. The actual error was four files away in opClock.cc, and pretty
hard to find. In Andrew's test, ithe compiler reports:

x.cc:1: error: expected constructor, destructor, or type conversion before 
string constant 

Note that here the cited line is line 1, i.e. the line where the cited string
constant appears and so Andrew's case gives the right line/file, whereas the
original does not.

If in the original the same message had given the line/file of the "string
constant" it mentions (which was the file name in what was intended to be a
#include) I'd be happy, but it doesn't.

I don't know what the difference is between the original report code and
Andrew's as far as the parser is concerned, but the location in the message in
the original is lousy while in Andrew's it's fine. I surmise that the line/file
reporting system is confused when the parser scans over an #include boundary (or
several); that happens in the original and not in Andrew's.

Ivan


-- 


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

[Bug c++/22590] parser does not recover well after error

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2005-07-22 03:16 -------
I believe you, though I can't reproduce with a simple set of include files. 
Can you try to reduce your program to something more reasonable that still 
shows the same problem? 
 
W. 

-- 


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

[Bug c++/22590] parser does not recover well after error

[igodard at pacbell dot net]

------- Additional Comments From igodard at pacbell dot net  2005-07-22 05:50 -------
# 1 "opClock.cc"
# 1 "/home/ivan/ootbc/members/src//"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "opClock.cc"
include "core.hh"
# 1 "../../members/include/opClock.hh" 1
# 1 "/mnt/export/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.0/../../../../includ
e/c++/3.4.0/cstddef" 1 3
# 1 "/mnt/export/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.0/include/stddef.h"
1 3 4
# 151 "/mnt/export/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.0/include/stddef.h
" 3 4
typedef int ptrdiff_t;


-- 


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

[Bug c++/22590] parser does not recover well after error

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2005-07-22 12:53 -------
I think I now get why I had less problems: this is already fixed in 4.0: 
 
g/x> /home/bangerth/bin/gcc-3.4*-pre/bin/c++ -c x.ii 
In file included 
from /mnt/export/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.0/../../../../include/c++/3.4.0/cstddef:1, 
                 from ../../members/include/opClock.hh:1, 
                 from opClock.cc:2: 
/mnt/export/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.0/include/stddef.h:151: 
error: expected constructor, destructor, or type conversion before string 
constant 
/mnt/export/local/bin/../lib/gcc/i686-pc-linux-gnu/3.4.0/include/stddef.h:151: 
error: expected `,' or `;' before string constant 
 
 
g/x> /home/bangerth/bin/gcc-4.0*-pre/bin/c++ -c x.ii 
In file included from ../../members/include/opClock.hh:2, 
                 from opClock.cc:3: 
opClock.cc:1: error: expected constructor, destructor, or type conversion 
before string constant 
 
 
So the error is now shown for the line of the .cc file. 
 
W. 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.0.0


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