On Thu, Feb 18, 2016 at 10:39:02PM +0100, Jakub Jelinek wrote:
> Hi!
>
> Here is an attempt to fix up the token reclassification after for statement,
> where we lexed the next token with the declaration from for in scope and
> need to undo that if it wasn't else.
>
> If token->id_kind is C_ID_CLASSNAME (ObjC only), then token->value has
> changed already, but in that case I think it means we can just keep it as
> is, it can't be shadowed by the for init declaration (because it would be
> C_ID_ID or C_ID_TYPENAME? otherwise).
> Otherwise, this patch tries to model the handling closer to what
> c_lex_one_token does, i.e. set it to C_ID_ID, except when decl is non-NULL
> and TYPE_DECL, or for the ObjC case where for init declaration shadowed
> a class declaration.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2016-02-18 Jakub Jelinek <ja...@redhat.com>
>
> PR objc/69844
> * c-parser.c (c_parser_for_statement): Properly handle ObjC classes
> in id_kind reclassification.
>
> * objc.dg/pr69844.m: New test.
>
> --- gcc/c/c-parser.c.jj 2016-02-16 16:29:54.000000000 +0100
> +++ gcc/c/c-parser.c 2016-02-18 17:36:55.025067859 +0100
> @@ -5887,12 +5887,27 @@ c_parser_for_statement (c_parser *parser
> {
> c_token *token = c_parser_peek_token (parser);
> tree decl = lookup_name (token->value);
> - if (decl == NULL_TREE || VAR_P (decl))
> - /* If DECL is null, we don't know what this token might be. Treat
> - it as an ID for better diagnostics; we'll error later on. */
> - token->id_kind = C_ID_ID;
> - else if (TREE_CODE (decl) == TYPE_DECL)
> - token->id_kind = C_ID_TYPENAME;
> + if (token->id_kind != C_ID_CLASSNAME)
> + {
> + token->id_kind = C_ID_ID;
I think let's sink the lookup_name call here. If id_kind is C_ID_CLASSNAME
we're not looking at decl at all.
> + if (decl)
> + {
> + if (TREE_CODE (decl) == TYPE_DECL)
> + token->id_kind = C_ID_TYPENAME;
> + }
> + else if (c_dialect_objc ())
> + {
> + tree objc_interface_decl = objc_is_class_name (token->value);
This objc_is_class_name is a weird stub that always returns NULL_TREE but
I know that the same code is in c_lex_one_token so let's keep it this way.
I've tried a bunch of invalid ObjC testcases and saw no ICEs and from the
C point of view this patch is safe.
Ok with that lookup_name change, thanks.
Marek
