On 8/20/24 9:11 AM, Franciszek Witt wrote:
Thanks for the feedback. I am attatching fixed patch as a file.
Pushed, thanks.
Regards
Franciszek
On Mon, 19 Aug 2024, 18:32 Jason Merrill, <ja...@redhat.com
<mailto:ja...@redhat.com>> wrote:
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
<mailto: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/ <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
<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
<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
<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
