On Mon, May 30, 2011 at 11:15 AM, Argyrios Kyrtzidis <[email protected]> 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. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
