On Tue, 2015-09-15 at 14:21 +0200, Manuel López-Ibáñez wrote:
> On 15/09/15 10:32, Mark Wielaard wrote:
> > On Mon, 2015-09-14 at 21:37 -0600, Martin Sebor wrote:
> > Although I now notice they differ on the placement of the carrot.
> > Maybe the location passed into the warning is not correct/ideal?
>
> The caret is placed at the location given by expand_location(loc), with loc
> being the location passed to warning_at(). As far as I am aware, there are no
> bugs on that. If the caret is wrong, it is definitely because the location
> passed is the wrong one. You need to find the correct one (which may appear
> up
> in the call stack and may need to be passed down) and pass that one instead.
>
> You can test the location with { dg-warning "18:nonnull argument" } where 18
> is
> the column number expected. I wish it was used more frequently, in particular
> in those cases where we have the perfect location and it would be pity to
> regress.
As Marin pointed out, this is not a new issue. Since build_binary_op
effectively only has one (input) location (and possibly the
DECL_SOURCE_LOCATIONS of the expressions, which are irrelevant in this
case) it is hard to get the location for the diagnostic precise. We
really need the locations of the expressions, not just the input
location of the binary op (which already seems a little inconsistent).
As you say we would have to audit each call to build_binary_op and
somehow pass through the location of op1 and op2 (if we actually have
them in the first place). Given the large number of ways build_binary_op
is called this doesn't seem feasible.
The real solution is probably something like David's "Add source-ranges
for trees" https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00739.html
David mentions several alternatives. I am not sure which one would be
the most acceptable.
Cheers,
Mark
