[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