On 16 May 2012 19:53, Paolo Carlini <pcarl...@gmail.com> wrote: >> - expr = build_new_op (loc, code, LOOKUP_NORMAL, arg1, arg2, NULL_TREE, >> + expr = build_new_op (LOC_OR_HERE (loc), code, LOOKUP_NORMAL, >> + arg1, arg2, NULL_TREE, >> overload, complain); >> >> This doesn't seem correct to me because of the reasons Jason gave. If >> loc is unknown, you are changing the behaviour. > > If loc is UNKNOWN I'm passing down an input_location which seems a definite > improvement to me in the light of your last message, given that the called > function may immediately error out and try to use that location in the > error_at. But I'm not going to insist. >
But then, this should have happened before, no? Or do we get UNKNOWN_LOCATION now but not before? That would indicate something has changed in an upper level that is not quite right. The point is that some things may naturally have UNKNOWN_LOCATION, however, such things should never be used in diagnostics. That indicates a bug. So, if the caller is passing down loc == UNKNOWN_LOCATION here and this new operation is never artificial, then the caller is wrongly passing down UNKNOWN_LOCATION. In this particular case, you may have just uncovered a latent bug, and use the LOC_OR_HERE trick to defer fixing it for later. That seems OK to me, but then you should add a FIXME for such case, saying "This should be just LOC but something is passing down UNKNOWN_LOCATION and this breaks so and so" I remember well that we had such nasty cases when Aldy and me did the column-information mega-patch, and still we got some of the locations wrong. Cheers, Manuel.
