On May 30, 2011, at 10:02 AM, Chandler Carruth wrote:
> On Sun, May 29, 2011 at 2:38 PM, Argyrios Kyrtzidis <[email protected]> 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 ?
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
