On 3/6/20 8:24 PM, Marek Polacek wrote:
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> }
And both are wrong; it should be
{ .ap = &a }
because the {} is initializing a.
Jason
