On 12/16/2015 10:13 AM, Bernd Schmidt wrote:
This is a relatively straightforward PR where we should mention a macro
expansion in a warning message. The patch below implements the
suggestion by Marek to pass a location down from
build_function_call_vec. Ok if tests pass on x86_64-linux?
One question I have is about -Wformat, which is dealt with in the same
area. We do get a mention of the macro expansion, but in a different style:
/* { dg-do compile } */
/* { dg-options "-Wformat" } */
int foox (const char *, ...) __attribute__ ((format (printf, 1, 2)));
#define foo(p, x) foox (p, x)
#define foo3(p, x, y) foox (p, x, y)
void
bar (unsigned int x)
{
foo ("%x", "fish");
foo3 ("%x", 3, "fish");
}
macroloc2.c: In function ‘bar’:
macroloc2.c:12:8: warning: format ‘%x’ expects argument of type
‘unsigned int’, but argument 2 has type ‘char *’ [-Wformat=]
foo ("%x", "fish");
^
macroloc2.c:6:25: note: in definition of macro ‘foo’
#define foo(p, x) foox (p, x)
^
macroloc2.c:13:9: warning: too many arguments for format
[-Wformat-extra-args]
foo3 ("%x", 3, "fish");
^
macroloc2.c:7:29: note: in definition of macro ‘foo3’
#define foo3(p, x, y) foox (p, x, y)
^
Is this what we're looking for in terms of output?
Are you referring to the "in definition" vs "in expansion" difference?
That appears to be a difference in the locus of the first displayed
diagnostic before the unwinding of the macros.
So in the case above, the first locus is outside the the macro
definitions (diagnostic for line #12) and we get the "in definition"
form. Similarly for the diagnostic on line #13 and the following note
using the "in definition" form.
In your pr66208.c testcase we get the following diagnostics after your
patch:
j.c: In function ‘baz’:
j.c:5:16: warning: null argument where non-null required (argument 1)
[-Wnonnull]
#define foo(p) foox (p, "p is null") /* { dg-warning "null argument" } */
^
j.c:9:3: note: in expansion of macro ‘foo’
foo (0); /* { dg-message "note: in expansion" } */
^~~
So the diagnostic is inside the macro, so according to tree-diagnostic.c
you should get the "in expansion" variant.
The difference may be an artifact of input_location's state when we
detect the error.
Jeff
