On Fri, Mar 06, 2020 at 07:40:20PM -0500, Jason Merrill wrote:
> On 3/6/20 11:02 AM, Marek Polacek wrote:
> > On Fri, Mar 06, 2020 at 04:58:32PM +0100, Paolo Carlini wrote:
> > > ... the patch ;)
> > >
> > > Paolo.
> > >
> >
> > > Fix "PR c++/94034 Broken diagnostic: 'result_decl' not supported by
> > > dump_expr"
> > >
> > > A rather simple diagnostic issue where we failed to handle RESULT_DECL in
> > > dump_expr.
> > >
> > > Tested x86_64-linux.
> > >
> > > /cp
> > > PR c++/94034
> > > * error.c (dump_expr): Handle RESULT_DECL like the other *_DECL.
> > >
> > > /testsuite
> > > PR c++/94034
> > > * g++.dg/cpp0x/pr94034.C: New.
> > >
> >
> > LGTM. In fact, I had the same patch.
> >
> > I think with this patch we print soemthing like "<result> <anonymous>"
> > which is still kind of ugly, but improving that is out of scope for GCC 10.
>
> Hmm, is that really so much better?
I would say it's better than
"'result_decl' not supported by dump_expr<expression error>". Since dump_expr
already handles a bunch of _DECL codes, we might as well add RESULT_DECL.
> Why do we end up trying to print a RESULT_DECL?
The r10-5821 patch changed a ctor from
{ .ap = &D.2344 }
to
{ .ap = &<retval> }
We should probably avoid printing such exprs altogether; I doubt people
are interested in seeing internal stuff like that.
Marek
