On 12/6/19 7:18 PM, Marek Polacek wrote:
[ Sorry for dropping the ball on this. ]
On Tue, Sep 17, 2019 at 11:59:02PM -0400, Jason Merrill wrote:
On 9/16/19 1:12 PM, Marek Polacek wrote:
On Sun, Sep 15, 2019 at 10:18:29AM -0400, Jason Merrill wrote:
On 9/5/19 9:24 PM, Marek Polacek wrote:
[ Sorry for dropping the ball on this. ]
On Tue, Sep 17, 2019 at 11:59:02PM -0400, Jason Merrill wrote:
> On 9/16/19 1:12 PM, Marek Polacek wrote:
> > On Sun, Sep 15, 2019 at 10:18:29AM -0400, Jason Merrill wrote:
> > > On 9/5/19 9:24 PM, Marek Polacek wrote:
> > > > They use
> > > >
On 9/16/19 1:12 PM, Marek Polacek wrote:
On Sun, Sep 15, 2019 at 10:18:29AM -0400, Jason Merrill wrote:
On 9/5/19 9:24 PM, Marek Polacek wrote:
They use
non_lvalue_loc, but that won't create a NON_LVALUE_EXPR wrapper around a
location
wrapper.
That seems like the bug. maybe_lvalue_p should
On Sun, Sep 15, 2019 at 10:18:29AM -0400, Jason Merrill wrote:
> On 9/5/19 9:24 PM, Marek Polacek wrote:
> > They use
> > non_lvalue_loc, but that won't create a NON_LVALUE_EXPR wrapper around a
> > location
> > wrapper.
>
> That seems like the bug. maybe_lvalue_p should be true for
>
On 9/5/19 9:24 PM, Marek Polacek wrote:
They use
non_lvalue_loc, but that won't create a NON_LVALUE_EXPR wrapper around a
location
wrapper.
That seems like the bug. maybe_lvalue_p should be true for
VIEW_CONVERT_EXPR.
Jason
Ping.
On Thu, Sep 05, 2019 at 10:24:55PM -0400, Marek Polacek wrote:
> Compiling this testcase results in a bogus "invalid cast" error; this occurs
> since the introduction of location wrappers in finish_id_expression.
>
> Here we are parsing the decltype expression via cp_parser_decltype_expr
Compiling this testcase results in a bogus "invalid cast" error; this occurs
since the introduction of location wrappers in finish_id_expression.
Here we are parsing the decltype expression via cp_parser_decltype_expr which
can lead to calling various fold_* and c-family routines. They use
