On 05/16/2012 12:54 PM, Paolo Carlini wrote:
I think I was wrong when I indicated that, and that EXPR_LOCATION is
better there, too. EXPR_LOC_OR_HERE is good for error messages, but
not for setting the location of a tree. Though it occurs to me that
we're likely to use the passed in location for errors as well, so we
had better make sure we're passing in a useful location.
Ok. Let's see if now I understand. This is what I did:
1- All the build_x_* callers pass EXPR_LOCATIONs (which can be
UNKNOWN_LOCATION)
2- Inside the build_x_*, the passed in location is used as-is in
template context to call build_min_nt_loc, and through a new
LOC_OR_HERE to call build_new_op and the like (which need something
meaningful for the error messages). Oh my.. at the risk of having to
send another iteration, which would be identical to this one but
without the LOC_OR_HERE thingy, isn't the diagnostic machinery able to
cope with UNKNOWN_LOCATION? By default should be interpreted as
input_location, no?
On the other hand - in case this is what you are thinking - I don't
believe we should try to surrogate an UNKNOWN location coming from
upstream with input_location also for the purpose of calling
build_min_nt_loc in template context. I can easily imagine cases where
it would be wrong, like we are parsing a binary operation, thus we can
only be past the second operand with the input_location when we call
build_x_binary_op, but the location we would like to pass to
build_min_nt_loc is that of the *operator*! Thus at this point in our
location work I don't believe we can do much (in terms of simple obvious
changes) for UNKNOWN_LOCATIONs coming from upstream, besides maybe using
the LOC_OR_HERE trick for the immediate error messages (but maybe isn't
really necessary).
Paolo.
