On 05/23/2012 04:52 AM, Dodji Seketeli wrote:
I tried to do what the C FE seems to do, which is to consider that the
default location (the global input_location variable) is on the LHS of
the assignment (on the usi variable), rather than on the token that
comes from DEC32_MAX.
That makes sense. Though really the relevant location would be the '='.
But then it regresses notably on tests like
testsuite/g++.dg/warn/pr35635.C:
void func3()
{
unsigned char uchar_x;
...
uchar_x = bar != 0
? (unsigned char) 1024
: -1; /* { dg-warning "negative integer implicitly converted to unsigned
type" } */
}
Regresses how? In this case the locus of the conversion is again the
'='. So the line number of the warning might change, but that doesn't
seem like a significant regression.
It seems to me that ultimately, things like conversion routines that
emit diagnostics should know about the expression that represents the
context in which they are emitting the said diagnostic. In this
particular case, warnings_for_convert_and_check should know about the
assignment expression "usi = DEC32_MAX", so that it can determine that
the whole expression is spelled in user code, and thus, the diagnostic
should be emitted. IOW, just knowing about the single token on which
the error occurs is not enough to decide.
I'm not sure I agree. We don't want to warn about a conversion that's
all within a macro from a system header, even if it is expanded within
an expression in user code. We just need to get the location right for
our diagnostics, which is an ongoing process, but we've been making a
lot of progress just recently.
Jason
