[Bug c/20385] New: Lame error message for undefined type

[Bug c/20385] New: Lame error message for undefined type

[falk at debian dot org]

% cat test.c
unknowntype f() { return 0; }

% gcc -c test.c
test.c:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'f'

Firstly, since this is a frequent mistake, we should really be able to produce
"unknowntype used like a type", as other compilers do.

Secondly, IMHO this kind of "expected ..." error message is *never* a good
idea. I cannot recall a single instance where it was actually helpful to me,
and very often, as in this case, it is extremely confusing, and I would be 
better off with plain "syntax error before f" as it used to be in the old
parser. Even though my knowledge of C parsing is probably slightly above 
average, I have not the slightest idea why the parser expects '=', ',', ';',
'asm' or '__attribute__' here, and what I can derive from that about the
mistake I made. But maybe that's just me.

-- 
           Summary: Lame error message for undefined type
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Keywords: diagnostic
          Severity: normal
          Priority: P2
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: falk at debian dot org
                CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c/20385] Lame error message for undefined type

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-08 18:33 -------
The `new' C++ parser gives the best error message:
t.c:1: error: 'unknowntype' does not name a type


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-03-08 18:33:18
               date|                            |


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

[Bug c/20385] Lame error message for undefined type

[joseph at codesourcery dot com]

------- Additional Comments From joseph at codesourcery dot com  2005-03-08 18:59 -------
Subject: Re:  New: Lame error message for undefined type

On Tue, 8 Mar 2005, falk at debian dot org wrote:

> % cat test.c
> unknowntype f() { return 0; }
> 
> % gcc -c test.c
> test.c:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'f'
> 
> Firstly, since this is a frequent mistake, we should really be able to produce
> "unknowntype used like a type", as other compilers do.
> 
> Secondly, IMHO this kind of "expected ..." error message is *never* a good
> idea. I cannot recall a single instance where it was actually helpful to me,
> and very often, as in this case, it is extremely confusing, and I would be 
> better off with plain "syntax error before f" as it used to be in the old
> parser. Even though my knowledge of C parsing is probably slightly above 
> average, I have not the slightest idea why the parser expects '=', ',', ';',
> 'asm' or '__attribute__' here, and what I can derive from that about the
> mistake I made. But maybe that's just me.

Functions can be defined without declaration specifiers in C90.  GNU C 
also allows (but pedwarns for) definitions (at file scope) of objects with 
no declaration specifiers (for example, "*foo;" meaning "int *foo;").  So 
"unknowntype" has been parsed as the name being declared at this point.  
So it must either be a function definition of a function called 
"unknowntype" (which it isn't as the declaration isn't a function one) or 
a data declaration, and the tokens listed are those which would follow 
"unknowntype" in a data declaration (for example, "unknowntype = 1; f() 
...").

It would be possible to have special-case detection for where empty 
declaration specifiers are followed by a declarator consisting only of an 
identifier, unparenthesised, and in the case of a parse error act like 
that identifier was a type and look for a new declarator.  This would 
cover "unknowntype foo;" and "unknowntype *foo;".  You can't detect 
undeclared types in full generality; for example,

unknowntype (foo)() { return 0; }

is syntactically valid C90 which should be diagnosed, as it is at present, 
as declaring a function "unknowntype" returning a function and so breaking 
a constraint, rather than the compiler second-guessing that "unknowntype" 
is a type and "(foo)" is the parenthesised function name.



-- 


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