On 11/17/2015 04:13 PM, David Malcolm wrote:
On Mon, 2015-11-16 at 22:34 +0100, Bernd Schmidt wrote:
Should c_expr perhaps acquire a constructor so that this problem is
avoided in the future? The whole thing seems somewhat error-prone.
I agree that it's error prone, and the ctor approach is what I've been
trying for the C++ FE [1] but I suspect that touching that in the C FE
would be a much more invasive patch (unless we simply give it a default
ctor that makes the src_range be a pair of UNKNOWN_LOCATIONS?).
The UNKNOWN_LOCATIONS pair would have been my approach, yes.
This case gains a pair of locals: start_loc and end_loc (so that we can
track the spelling range whilst retaining the "loc" used for the caret),
and I preferred to confine their scope to within the case, hence the
extra braced block. Omitting the braced block leads to:
../../src/gcc/c/c-parser.c:7494:7: error: jump to case label [-fpermissive]
case RID_OFFSETOF:
^
../../src/gcc/c/c-parser.c:7472:17: error: crosses initialization of
‘location_t end_loc’
location_t end_loc = c_parser_peek_token (parser)->get_finish ();
^
etc.
Hmm, odd, I tried placing just the location_t start_loc line into the
switch and that appeared to compile fine. But I guess this is not a huge
problem.
Is the combination of the 3 patches OK for trunk? (assuming
bootstrap®rest; it's only the braced-init tweak that hasn't been).
Yes.
Bernd
