Re: [PATCH 3/6] Emit macro expansion related diagnostics

[Dodji Seketeli <dodji@redhat.com>]

Paolo Bonzini <bonzini@gnu.org> writes:

> On 12/10/2010 12:11 PM, Dodji Seketeli wrote:
>> [dodji@adjoa gcc]$ ./cc1 -quiet -ftrack-macro-expansion test.c
>> test.c: In function ‘g’:
>> test.c:5:14: error: invalid operands to binary<<  (have ‘double’ and ‘int’)
>> In macro 'OPERATE' at test.c:2:9
>>      Expanded at test.c:5:3
>> In macro 'SHIFTL' at test.c:5:14
>>      Expanded at test.c:8:3
>> In macro 'MULT' at test.c:8:3
>>      Expanded at test.c:13:3
>> 
>
> I'm not sure I share Jeff's doubts about the location to present.
> Possibly _this_ could be controlled by a flag, though.
>
> Also, I know this is just an RFC, but the error message should
> probably look like either this example:
>
> test.c:5:14: error: invalid operands to binary<<  (have ‘double’ and ‘int’)
> test.c:2:9: note: in expansion of macro 'OPERATE'
> test.c:5:3: note: expanded from here
> test.c:5:14: note: in expansion of macro 'SHIFTL' 
> test.c:8:3: note: expanded from here
> test.c:8:3: note: in expansion of macro 'MULT'
> test.c:13:3: note: expanded from here

Sorry if I am dig into design consideration when we are talking about
UI, but I think it is needed to clarify things here.

The current custom in the compiler is that the "<locus> note:" prefix is
displayed only when client code explicitely calls the 'inform'
function. That sets the diagnostic kind to DK_NOTE.

This seems a little bit different from what is done for macro expansion
contexts.

The macro expansion context is unwound implicitly. That is, the client
code calls e.g:

    error_at (some_location, "An error occured")

and if some_location appears to be the location of a token resulting
from macro expansion the diagnostic machinery unwinds the expansion
context and displays it to the user, regardless of what the diagnostic
kind was.  So the context lines are not prefixed with "<locus> note:" as
the context is generated implicitely.  This is similar to what G++ does
when it displays template instantiation contexts.

On the other hand, I find the "<locus> note:" usage more regular and
thus easier to parse for tools that interact with the output of the
compiler. So there could be some value in us using that prefix.

However if we are to use that prefix for implicitely displayed contexts,
I think we should factorize diagnostic_build_prefix to allow using the
same prefix as the one used for e.g. DK_NOTE. Would that be acceptable?

-- 
	Dodji