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

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

[bonzini at gnu dot org]

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

--- Comment #5 from Paolo Bonzini <bonzini at gnu dot org> 2010-11-13 10:01:38 UTC ---
Author: bonzini
Date: Sat Nov 13 10:01:33 2010
New Revision: 166700

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166700
Log:
2010-10-30  Paolo Bonzini  <bonzini@gnu.org>

    PR c/20385
    * c-parser.c (c_parser_next_token_starts_declaration): Rename to...
    (c_parser_next_tokens_start_declaration): ... this.  Handle 2nd
    token lookahead.
    (c_parser_compound_statement_nostart, c_parser_label,
    c_parser_for_statement, c_parser_omp_for_loop): Adjust calls.
    (c_parser_declaration_or_fndef): Detect the case now matched by
    c_parser_next_tokens_start_declaration, give error and correct it.

testsuite:
2010-11-13  Paolo Bonzini  <bonzini@gnu.org>

    PR c/20385
    * gcc.dg/decl-9.c: New.


Added:
    trunk/gcc/testsuite/gcc.dg/decl-9.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/c-parser.c
    trunk/gcc/testsuite/ChangeLog

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

[bonzini at gnu dot org]

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

Paolo Bonzini <bonzini at gnu dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bonzini at gnu dot org

--- Comment #6 from Paolo Bonzini <bonzini at gnu dot org> 2010-11-15 15:16:44 UTC ---
Still doesn't get function parameters right, i.e.

int f(unknowntype a) { return 0; }
int g(unknowntype *a) { return 0; }

gives

f.c:1:19: error: expected ‘)’ before ‘a’
f.c:2:19: error: expected ‘)’ before ‘*’ token

Fixing it shouldn't be too hard, though.

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

[manu at gcc dot gnu.org]

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

--- Comment #7 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2010-11-15 16:10:31 UTC ---
And what about the undefined return type?

unknowntype f() { return 0; }
unknowntype *f() { return 0; }


If you fix this bug once and for all, please mention it in
gcc-4.6/changes.html, because this is a very significant improvement!

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

[bonzini at gnu dot org]

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

--- Comment #8 from Paolo Bonzini <bonzini at gnu dot org> 2010-11-15 16:24:52 UTC ---
That works.

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

[bonzini at gnu dot org]

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

--- Comment #9 from Paolo Bonzini <bonzini at gnu dot org> 2010-11-17 16:14:32 UTC ---
Another case in which we still do not detect the unsigned type is after
declspecs:

typedef uintt16_t pid_t;
extern uintt16_t x;

I think that until this is fixed, there are still enough "bad" cases that it's
not worth putting it into the release notes.

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

[bonzini at gnu dot org]

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

--- Comment #10 from Paolo Bonzini <bonzini at gnu dot org> 2010-12-17 21:23:38 UTC ---
Author: bonzini
Date: Fri Dec 17 21:23:36 2010
New Revision: 167999

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167999
Log:
gcc:
2010-12-17  Paolo Bonzini  <bonzini@gnu.org>

    PR c/20385
    * function.c (used_types_insert): Handle ERROR_MARK.
    * c-decl.c (grokdeclarator): Handle ERROR_MARK.
    (declspecs_add_type): Leave error_mark_node in specs->type.
    (finish_declspecs): Change it to integer_type_node here.
    * c-parser.c (c_parser_peek_2nd_token): Move earlier.
    (enum c_lookahead_kind): New.
    (c_parser_next_token_starts_typename): New name of
    c_parser_next_tokens_start_typename.  Accept lookahead enum
    and handle it here instead of...
    (c_parser_next_tokens_start_declaration): ... here.  Call it.
    (c_parser_declspecs): Accept another argument.  Do not exit
    on C_ID_ID if it is guessed to be an unknown typename.
    (c_parser_parms_declarator): Use 2nd token to distinguish a K&R
    declaration from an ANSI declaration starting with an unknown
    typename.
    (c_parser_struct_declaration, c_parser_objc_type_name,
    c_parser_typeof_specifier, c_parser_declarator,
    c_parser_direct_declarator_inner): Adjust calls.
    (c_parser_parameter_declaration): Likewise.
    (c_parser_type_name): Pass back an error_mark_node to the caller.
    (c_parser_postfix_expression): Do error recovery when 
    c_parser_type_name returns NULL.

testsuite:
2010-12-17  Paolo Bonzini  <bonzini@gnu.org>

    PR c/20385
    * objc.dg/tls/init-2.m: Adjust.
    * gcc.dg/noncompile/920923-1.c: Adjust.
    * gcc.dg/noncompile/pr44517.c: Adjust.
    * gcc.dg/declspec-18.c: New test.


Added:
    trunk/gcc/testsuite/gcc.dg/declspec-18.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/c-decl.c
    trunk/gcc/c-parser.c
    trunk/gcc/function.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/noncompile/920923-1.c
    trunk/gcc/testsuite/gcc.dg/noncompile/pr44517.c
    trunk/gcc/testsuite/objc.dg/tls/init-2.m

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

[manu at gcc dot gnu dot org]

------- Comment #4 from manu at gcc dot gnu dot org  2009-10-15 15:21 -------
BTW, Clang claims to get this right. Quoting from:
http://clang.llvm.org/diagnostics.html

  $ gcc-4.2 t.c
  t.c:3: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*'
token
  $ clang t.c
  t.c:3:1: error: unknown type name 'foo_t'
  foo_t *P = 0;
  ^

This shows an example of much better error recovery. The message coming out of
GCC is completely useless for diagnosing the problem, Clang tries much harder
and produces a much more useful diagnosis of the problem.


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2005-12-18 01:43:44         |2009-10-15 15:21:34
               date|                            |


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

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

[manu at gcc dot gnu dot org]

------- Comment #3 from manu at gcc dot gnu dot org  2008-08-18 18:28 -------
This is hard. Even the simple cases are hard since the error is detected very
very late. There are far too many ways to declare anything. Perhaps using a
slightly different code patch for C99 would help with -std=c99.

Deprecating the GNU C extension that allows definitions at file scope of
objects with no declaration specifiers would simplify things.

But in the end I think we would need to parse the whole declaration more or
less tentatively before figuring out which errors emit. I think not diagnosing
"unknown type" for the following testcase is ok:

unknowntype (foo)() { return 0; }

We should be worried about simpler cases like:

unknowntype f() { return 0; }
unknowntype *f() { return 0; }

int f(unknowntype a) { return 0; }
int f(unknowntype *a) { return 0; }

unknowntype a;
unknowntype *a;

and so on. Those are the ones users complain about. Also, if other compilers
get them right, then surely we can get them right as well. Now we only need
some brave volunteer to implement it ;-)


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Lame error message for      |Lame parse error message for
                   |undefined type              |undefined type


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