On Sun, 13 Sep 2020, Uecker, Martin wrote:
> Hi Joseph,
>
> here is the (unfinished) patch to support
> mixing of labels in C2X.
I think there should be explicit tests for old standard versions
(c11-labels-1.c etc.) that these usages are errors with -pedantic-errors
with the old -std option, are warnings with -pedantic, and are quietly
accepted with neither. In addition to using -pedantic-errors with the new
standard version test to confirm it's not diagnosed, and a test with the
new version and -Wc11-c2x-compat.
By way of example of further places that I think need changing in the
patch: at present, c_parser_label gives an error (that you correctly
change to a pedwarn_c11) if the label is followed by a declaration - and
then parses the declaration itself rather than leaving it to be parsed in
the caller. So c_parser_compound_statement_nostart would parse a label
followed by a declaration, and at that point last_label would be set to
true, meaning that a second declaration would be rejected, when in C2x it
should be accepted. You can see this even without the patch with a test
such as:
void
f (void)
{
label : int a; int b;
}
I think that instead c_parser_label should never try to parse a
declaration following the label; that should be left for the caller to
handle. To avoid c_parser_label needing to return information about
standard attributes on a following declaration, maybe it shouldn't parse
standard attributes either (note that means that c_parser_all_labels would
need to handle parsing and warning about and discarding standard
attributes after each label instead - such attributes might be ones on a
statement, or ones on the next label in a sequence of labels).
Then of course the checks of last_label in
c_parser_compound_statement_nostart would need to become checks for
whether to pedwarn_c11 about the use of a label in a given context, once
the code knows whether there is a declaration, rather than preventing
parsing a declaration there at all. So probably c_parser_label would no
longer have the pedwarn_c11 either; that would all be left to its callers.
--
Joseph S. Myers
jos...@codesourcery.com
