[cfe-commits] r132247 - in /cfe/trunk: include/clang/Basic/SourceManager.h lib/Basic/SourceManager.cpp

[Chandler Carruth]

On Mon, May 30, 2011 at 11:15 AM, Argyrios Kyrtzidis <akyrtzi at gmail.com> wrote:
> Yeah but is the cost unacceptable ? We only do this to display the
> diagnostic.

I'm not sure. I'm worried about exactly how complex this is going to
be to implement. Especially considering how meaningless our current
source locations are for arguments to function style macros. We at
least need some sound model for the source locations of macro
arguments, especially as the preprocessor uses these source locations
heavily (for example, they guide the production of -E output). Several
of my early attempts to improve the diagnostics put somewhat
artificial locations here that simply happened to work out well for
the diagnostic client, and those failed because the rest of Clang
expected them to fit into a specific model. Anyways, I'm interested in
where you're imagining going with this, I'm just suspecting it will
end up being orthogonal to my patch.... If not, great!

> Nevertheless I'm not opposed to your patch if it doesn't affect
> normal performance.

Cool! I just posted new performance numbers to the bug. If they look
reasonable, I'll move forward with committing the patch, and then we
should have a better baseline for further work.

> I'm mostly interested in providing a general solution to
> clients for analyzing macros without having to resort to re-lexing the whole
> translation unit (!).
>
> We can already get a list of tokens, we just don't expose it to clients; we
> can provide a list of all the source locations of the macro tokens and the
> client can derive a list of the spelling locations/tokens.

...

> Let's say:
> #define M1 blah \
>            blah \
>            foo
> I want to be able to say "the token came from a macro whose definition is
> here:
> #define M1 blah \
>         ^
> How do you do that with the spelling location chain ?

In theory, we could derive this from the existing information by
working backwards through the token stream to the #define. If we're
expecting the clients of this interface to be re-processing the token
stream of the definition, that shouldn't be prohibitively expensive.
However, it might be really annoying code to write. If so, I'd not be
opposed to adding information to the InstantionInfo struct.

As a potential alternative to storing the source location in the
InstantiationInfo, what if you stored a pointer to the IndentifierInfo
of the macro? We should then be able to get the MacroInfo struct from
the Preprocessor, which has lots of very useful information about
macros already. I haven't checked whether we get two different
IdentifierInfo*'s when we hit something like:

#define M A
M
#undef M
#define M B
M

But ideally something that gets us back to the MacroInfo struct for
the definition used during the instantiation would make the subsequent
APIs much easier to craft.