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

Argyrios Kyrtzidis akyrtzi at gmail.com
Mon May 30 11:15:19 PDT 2011


On May 30, 2011, at 10:02 AM, Chandler Carruth wrote:

> On Sun, May 29, 2011 at 2:38 PM, Argyrios Kyrtzidis <akyrtzi at gmail.com> wrote:
>> I completely agree and the extra info about argument expansion is a great improvement but it still doesn't provide *all* the info a client may need to fully explore a macro expansion.
>> 
>> I think what a client ultimately needs (and hopefully Abramo may offer further insights) is 2 things, a list of all the locations of tokens of the macro expansion and the source location of the macro definition that was responsible for the expansion.
> 
> This isn't sufficient for some of our applications, and I don't think
> is sufficient to generate these diagnostics.
> 
> We also need to know what tokens come from macro arguments as opposed
> to the macro definition's tokens.
> 
> Currently, the lexer expands function-style macros recursively on
> demand. This means that we actually don't have a token sequence
> representing the definition of the macro (pre-expansion). I actually
> like this because it accurately reflects the defined semantics of the
> preprocessor.
> 
> What we need are for the source locations of each token in the fully
> expanded token stream to accurately represent whether the token was
> expanded directly from the macro definition's tokens, or whether it
> was expanded first from the argument token stream into the macro
> definition token stream, and then back into the final fully-expanded
> token stream. That's precisely what my patch does.
> 
> I also don't think we need to store any extra info to find the
> location of a macro definition. It should be the immediate spelling
> location. Macro arguments have a second instantiation record that will
> take you back to the original spelling location in the call site, but
> its first spelling location step should step into macro definition.
> 
>> All info that a client may need can be derived/reconstructed by these 2 pieces of info and we can offer helper routines for the more commonly useful info (e.g. for the position of the macro argument, or the source range of the input to the macro argument).
> 
> It's not clear to me how you get the position of the macro argument
> without re-lexing... which would be really unfortunate cost.

Yeah but is the cost unacceptable ? We only do this to display the diagnostic. Nevertheless I'm not opposed to your patch if it doesn't affect normal performance. 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.
>> We are unable to provide the location of the macro definition responsible for the expansion because we don't keep it anywhere. Maybe add a SourceLocation in InstantiationInfo ?
> 
> I think this is already available via the spelling location chain...


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 ?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20110530/385c81c4/attachment.html>


More information about the cfe-commits mailing list