[cfe-dev] [PATCH] Automatic detection of compatibility macros for non-portable diagnostics

[David Blaikie]

On Fri, Jul 27, 2012 at 4:11 PM, Chandler Carruth <chandlerc at google.com> wrote:
> On Fri, Jul 27, 2012 at 4:07 PM, Alexander Kornienko <alexfh at google.com>
> wrote:
>>
>> On Fri, Jul 27, 2012 at 11:40 PM, Chandler Carruth <chandlerc at google.com>
>> wrote:
>>>
>>> FWIW, at a high level I find the callback approach is very worrisome.
>>>
>>> The callback system was designed to be fast when the callbacks were
>>> completely null, and impose a non-trivial cost on the preprocessor
>>> otherwise.
>>
>> I do not think that we'll get measurably worse performance as a result of
>> this change. This code only works on macro definitions (does anyone know how
>> many of those per translation unit should we expect IRL?),
>
>
> Boost provides libraries that do terrifying things here. I don't think we
> can count on this number being "small".
>
>>>
>>> Can we not walk back through the macro definitions after-the-fact? I
>>> would expect the preprocessor to still have all the information we need.
>>
>> I'm not sure that we retain contents of #undef'ed and redefined macros.
>> And we definitely need this as we run analysis after the whole file is
>> lexed.
>
>
> But I would expect the macros we're particularly interested in
> (compatibility ones) would not be undef'ed anywhere...

Yeah, that's the approach we take with NULL for example - we just
check if it's defined (& we're emitting these warnings potentially at
the end of the TU or function - so we don't get precision macro
state/could be wrong in particular cases of def/undef). Doesn't seem
unreasonable to me here there or here.

- David