On Wed, 2017-10-25 at 09:59 -0600, Jeff Law wrote: > On 10/11/2017 01:32 PM, David Malcolm wrote: > > [This patch assumes the two patches here: > > https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00274.html ] > > I see the patch directly referenced in that message on the > trunk. But > I'm not sure what you mean by "two patches". If there's a prereq > that > hasn't been approved, let me know.
Sorry about the confusion; the one at the URL above was: "[PATCH 2/2] C/C++: add fix-it hints for various missing symbols (v3)", which is an updated version of: "[PATCH 2/2] C/C++: add fix-it hints for various missing symbols (v2)" https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01746.html the other one I was referring to was: "[PATCH 1/2] C++: avoid partial duplicate implementation of cp_parser_error" https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01745.html Both these prereqs are in trunk (as r253686 and r253690 respectively). > > > > > c_parser_declaration_or_fndef has logic for parsing what might be > > either a declaration or a function definition. > > > > This patch adds a test to detect cases where a semicolon would have > > terminated the decls as a declaration, where the token that follows > > would start a new declaration specifier, and updates the error > > message > > accordingly, with a fix-it hint. > > > > This addresses PR c/7356, fixing the case of a stray token before a > > #include which previously gave inscrutable output, and improving > > e.g.: > > > > int i > > int j; > > > > from: > > > > t.c:2:1: error: expected '=', ',', ';', 'asm' or '__attribute__' > > before 'int' > > int j; > > ^~~ > > > > to: > > > > t.c:1:6: error: expected ';' before 'int' > > int i > > ^ > > ; > > int j; > > ~~~ > > > > The patch also adds a test for PR c/44515 as a baseline. > > Personally I find the current error easier to digest. It quite > clearly > tells me to look before the current token and shove in an appropriate > thingie :-) The extra vertical space, to me, makes the error > message > harder to parse. You've been using gcc for multiple decades and are used to the existing behavior, though ;) > But I can see how others would prefer to see the point where the > punctuation was missing. So I won't let my biases get in the way > here. FWIW the benefit is a *lot* clearer for the first case described, where the two locations are in different source files due to the missing semicolon being immediately before a #include (PR c/7356), or at the end of a header; it replaces dozens of crazy-looking errors with a single sane one. > > gcc/c/ChangeLog: > > PR c/7356 > > * c-parser.c (c_parser_declaration_or_fndef): Detect missing > > semicolons. > > > > gcc/testsuite/ChangeLog: > > PR c/7356 > > PR c/44515 > > * c-c++-common/pr44515.c: New test case. > > * gcc.dg/pr7356-2.c: New test case. > > * gcc.dg/pr7356.c: New test case. > > * gcc.dg/spellcheck-typenames.c: Update the "singed" char > > "TODO" > > case to reflect changes to output. > > * gcc.dg/noncompile/920923-1.c: Add dg-warning to reflect > > changes > > to output. > > OK. Thanks; committed to trunk as r254093 (and closing out PR c/7356 after 15 years!) Dave
