Hi folks.
I'm looking at 3544[123] and 35742, which are all related to
pp_c_expression not handling complex expressions, so we can't display
correct error messages for statement expressions, etc:
({break;})()
The error here is currently:
#'goto_expr' not supported by pp_c_expression#'bug.c: In function 'foo':
bug.c:4: error: called object is not a function
I've looked into what needs to happen to give correct error messages.
First, I believe this is foremost a representation problem. We can't
give accurate error messages if we keep reconstructing the original
sources from GENERIC.
For example, in the above example, the error machinery thinks we're
talking about a GOTO_EXPR, because GENERIC has no way of representing
BREAK/CONTINUE.
Similary, when we ignore the result of a function call, many FE's create
an artificial variable. For "extern int foo(); foo();", the
representation is actually "<D.6789> = foo()", which will also be
unreadable even if handled by pp_c_expression.
It seems to me that the only approach here would be to provide caret
diagnostics, because reconstructing the original sources from GENERIC
seems like a loosing proposition.
But, is this slew of work even worth it? I for one think that the
aforementioned PRs should at least be marked down considerably. 3 of
them are P2s-- and I think they should be some Pn+5, and/or mark them as
an enhancement request.
Are there any thoughts on this (the PRs, the caret diagnostics, plan of
attack, etc?).
Aldy
