On 8/19/24 12:01 PM, Jason Merrill wrote:
On 8/19/24 6:01 AM, Jonathan Wakely wrote:
On 05/08/24 09:32 +0200, Franciszek Witt wrote:
Author: Franciszek Witt <franek.w...@gmail.com>
Date: Mon Aug 5 09:00:35 2024 +0200
c++: [PR101232]
The line above should be the first line of your Git commit message,
which should be in the form "component: Summary of change [PRnnnn]"
The Subject: of your email seems like it should be repeated here
(although something shorter would be even nicer, if possible).
https://cbea.ms/git-commit/
PR c++/101232
gcc/cp/ChangeLog:
* parser.cc (cp_parser_postfix_expression): Commit to the
parse in case we know its either a cast or invalid syntax.
(cp_parser_braced_list): Add a heuristic to inform about
missing comma or operator.
The ChangeLog part of the commit message should follow the rules in
the GNU Coding Standards:
https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html
Specifically, they should be wrapped to fit in an 80 column terminal
window. I think wrapping around 76 columns is common. Please add line
breaks here, e.g.
* parser.cc (cp_parser_postfix_expression): Commit to the
parse in case we know its either a cast or invalid syntax.
(cp_parser_braced_list): Add a heuristic to inform about
missing comma or operator.
(but with a leading TAB, not spaces).
Agreed. In addition, we need DCO certification or copyright assignment
(https://gcc.gnu.org/contribute.html#legal).
Also, the patch itself was corrupted by word wrap in your mail client,
so it doesn't apply, e.g.:
@@ -7881,8 +7881,13 @@ cp_parser_postfix_expression (cp_parser
*parser, bool address_p, bool cast_p,
https://www.kernel.org/doc/html/latest/process/email-clients.html has
some tips for avoiding word wrap, or you can just attach the patch
instead of pasting it inline.
+ /* This is just a heuristic. */
Two spaces after the .
+ inform (finish_loc, + "probably missing a comma
or an operator before");
The string should line up after the ( on the previous line.
We might as well also put this inform under the
cp_parser_skip_to_closing_brace check; if there's no } at all, the
problem isn't a missing comma...
Also, error59 seems like an error-recovery regression:
+++ b/gcc/testsuite/g++.dg/parse/error59.C
@@ -3,4 +3,4 @@
void foo()
{
(struct {}x){}; // { dg-error "" }
-}
+} // { dg-excess-errors "" }
as we now get more of an error cascade. Perhaps also check the return
value of the earlier require_open and don't skip_to_closing_brace if it
failed?
Jason
