[PATCH] PR c/20385: more detection of unknown type names

Joseph S. Myers joseph@codesourcery.com
Thu Nov 25 07:19:00 GMT 2010


On Sun, 21 Nov 2010, Paolo Bonzini wrote:

> @@ -1922,12 +1945,12 @@ c_parser_static_assert_declaration_no_se
>  
>  static void
>  c_parser_declspecs (c_parser *parser, struct c_declspecs *specs,
> -		    bool scspec_ok, bool typespec_ok, bool start_attr_ok)
> +		    bool scspec_ok, bool typespec_ok, bool start_attr_ok,
> +		    bool nonabstract_decl)

I don't see an update of the comment above this function (starting quite a 
long way above) to explain the new parameter.

> -          /* If we cannot accept a type, and the next token must start one,
> -	     exit.  Do the same if we already have seen a tagged definition,
> -	     since it would be an error anyway and likely the user has simply
> -	     forgotten a semicolon.  */
> -          if ((!typespec_ok || specs->typespec_kind == ctsk_tagdef)
> -	      && c_parser_next_token_starts_typename (parser))
> -            break;
> +          la = nonabstract_decl ? cla_nonabstract_decl : cla_prefer_type;
> +          if (c_parser_next_tokens_start_typename (parser, la))
> +            {
> +              /* We cannot accept a type, and the next token must start one;
> +                 exit.  Do the same if we already have seen a tagged definition,
> +                 since it would be an error anyway and likely the user has simply
> +                 forgotten a semicolon.  */
> +              if (!typespec_ok || specs->typespec_kind == ctsk_tagdef)
> +                break;

As far as I can see, this rewording of the comment is incorrect; inside 
the outer if, we don't yet know that "We cannot accept a type", that's the 
first condition of the inner if.  I think the original wording would still 
have been correct here.

Also, I'm concerned about the interaction of the new parameter with the 
!typespec_ok case.  Logically, I don't think the new parameter should 
matter at all in that case; if type names aren't valid (as in qualifiers 
in pointer and array declarators), this function shouldn't attempt to 
guess what undeclared identifiers might be, it should just return for 
them.

-- 
Joseph S. Myers
joseph@codesourcery.com



More information about the Gcc-patches mailing list