On Tue, Aug 30, 2016 at 01:08:22PM -0400, Jason Merrill wrote:
> On Tue, Aug 30, 2016 at 10:25 AM, Marek Polacek <pola...@redhat.com> wrote:
> >> > @@ -10585,15 +10610,26 @@ cp_parser_statement (cp_parser* parser, tree
> >> > in_statement_expr,
> >> > }
> >> > /* Look for an expression-statement instead. */
> >> > statement = cp_parser_expression_statement (parser,
> >> > in_statement_expr);
> >> > +
> >> > + /* Handle [[fallthrough]];. */
> >> > + if (std_attrs != NULL_TREE
> >> > + && is_attribute_p ("fallthrough", get_attribute_name
> >> > (std_attrs))
> >> > + && statement == NULL_TREE)
> >> > + {
> >> > + tree fn = build_call_expr_internal_loc (statement_location,
> >> > + IFN_FALLTHROUGH,
> >> > + void_type_node, 0);
> >>
> >> Let's use the 'statement' variable rather than a new variable fn so
> >> that we set the call's location below. Let's also warn here about
> >> [[fallthrough]] on non-null expression statements.
> >
> > Done. But I couldn't figure out a testcase where the warning would
> > trigger, so
> > not sure how important that is.
>
> What happens for
>
> [[fallthrough]] 42;
>
> ? What ought to happen is a warning that the attribute only applies
> to null statements.
This:
q.C: In function ‘void f(int)’:
q.C:8:8: error: expected identifier before ‘[’ token
[[fallthrough]] 42;
^
q.C: In lambda function:
q.C:8:23: error: expected ‘{’ before numeric constant
[[fallthrough]] 42;
^~
And the same with e.g. [[unused]]. G++ 6 behaves exactly the same,
so it isn't something my patch changed. It seems we never even reach
the code in question, at least std_attrs is null.
It seems g++ is trying to parse a lambda expression.
Marek
