broken FE diagnostics wrt complex expressions

[Aldy Hernandez <aldyh at redhat dot com>]

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