[05/11] Make expand_location resolve to locus in main source file

Apparently, quite some places in the compiler (like the C/C++
preprocessor, the debug info machinery) expect expand_location to
resolve to locations that are in the main source file, even if the
token at stake comes from a macro that was defined in a header
somewhere.  Turning on -ftrack-macro-expansion by default was
triggering a lot of failures (not necessarily related to diagnostics)
because expand_location resolves to spelling locations instead.

So I have changed expand_location to honour the initial expectation.

In addition, I came up with the new expand_location_to_spelling_point
used in diagnostic_build_prefix because the diagnostic system, on the
other hand, wants to point to the location of the token where it was
spelled, and then display the error context involving all the macro
whose expansion led to that spelling point - if we are in the context
of a macro expansion there.

This seems to me like a reasonable balance.

Tested and bootstrapped on x86_64-unknown-linux-gnu against trunk and
whitnessed that a lot more tests were PASSing.

Note that the bootstrap with -ftrack-macro-expansion exhibits other
separate issues that are addressed in subsequent patches.  This patch
just fixes one class of problems.

The patch does pass bootstrap with -ftrack-macro-expansion turned off,
though.

gcc/

	* input.c (expand_location_1): New.  Takes a parameter to choose
	whether to resolve the location to spelling or expansion point.
	Was factorized from ...
	(expand_location): ... here.
	(expand_location_to_spelling_point): New.  Implemented in terms of
	expand_location_1.
	* diagnostic.c (diagnostic_build_prefix): Use the new
	expand_location_to_spelling_point instead of expand_location.
---
 gcc/diagnostic.c |    2 +-
 gcc/input.c      |   39 ++++++++++++++++++++++++++++++++++-----
 gcc/input.h      |    9 +++++++++
 3 files changed, 44 insertions(+), 6 deletions(-)

On 04/10/2012 03:49 PM, Dodji Seketeli wrote:
> Apparently, quite some places in the compiler (like the C/C++
> preprocessor, the debug info machinery) expect expand_location to
> resolve to locations that are in the main source file, even if the
> token at stake comes from a macro that was defined in a header
> somewhere.  Turning on -ftrack-macro-expansion by default was
> triggering a lot of failures (not necessarily related to diagnostics)
> because expand_location resolves to spelling locations instead.

Can you elaborate on these failures?  For debug info I would think that 
the spelling location would be useful information, though I suppose 
without any way to "unwind" to the expansion context it could be a bit 
confusing.  What is the problem for the preprocessor?

Jason

> On 04/10/2012 03:49 PM, Dodji Seketeli wrote:
>> Apparently, quite some places in the compiler (like the C/C++
>> preprocessor, the debug info machinery) expect expand_location to
>> resolve to locations that are in the main source file, even if the
>> token at stake comes from a macro that was defined in a header
>> somewhere.  Turning on -ftrack-macro-expansion by default was
>> triggering a lot of failures (not necessarily related to diagnostics)
>> because expand_location resolves to spelling locations instead.
>
> Can you elaborate on these failures?  For debug info I would think
> that the spelling location would be useful information, though I
> suppose without any way to "unwind" to the expansion context it could
> be a bit confusing.  What is the problem for the preprocessor?

For the preprocessor, consider a short excerpt of the the test
gcc/testsuite/gcc.dg/cpp/avoidpaste1.c:

    #define f(x) x
    #define g
    #define tricky 1.0e ## -1

    :: :g: :f(): :f(^): tricky

As the comment in the text says, it should preprocess as:

    :: : : : : :^: 1.0e- 1

but it actually preprocess as:

    # 1 "/home/dodji/devel/git/gcc/tmp/gcc/testsuite/gcc.dg/cpp/avoidpaste1.c"
    # 1 "<command-line>"
    # 1 "/home/dodji/devel/git/gcc/tmp/gcc/testsuite/gcc.dg/cpp/avoidpaste1.c"
    # 25 "/home/dodji/devel/git/gcc/tmp/gcc/testsuite/gcc.dg/cpp/avoidpaste1.c"
    :: : : : : :^:
    # 14 "/home/dodji/devel/git/gcc/tmp/gcc/testsuite/gcc.dg/cpp/avoidpaste1.c"
		   1.0e- 1

Note how the "1.0e- 1" is not on the same line as its preceding
":: : : : : :^:".

The problem is that the pre-processor code indirectly uses
expand_location in many spots.  For that kind of existing code that is
not related to diagnostics, I am really not confident in changing the
underlying implicit assumption of the that function which is, to
return the expansion point location.  I don't even know before hand
where all these spots are in the code base, so auditing it is hard for
me.

I forgot to say that are also other weird failure like:

    FAIL: g++.dg/cdce3.C -std=gnu++98 scan-tree-dump cdce "cdce3.C:92: note: function call is shrink-wrapped into error conditions."

due to that change.

That's why I prefer erring on the safe side by not changing the
assumption of existing code, and provide a way to expand locations to
their spelling point, just for diagnostics.  I think this is already
an improvement over what we previously had.

And for the debug info cases, I'd propose that if we find specific
examples where the unwinding to the spelling locations is better, then
we'll consider using it at that moment.