[cfe-dev] ASTMatchers.h and its internal linkage variable definitions

David Blaikie via cfe-dev cfe-dev at lists.llvm.org
Mon Nov 13 15:53:44 PST 2017


Ping?

Richard & I decided that supporting this particular case of namespace-scope
static variables in modular headers using modular codegen. (specifically
the case where the namespace-scope static variable is referenced from an
inline function - thus making a true ODR violation (in classic C++ this'd
be an ODR violation if more than one TU used that header - so it seems OK
to not support this in modular codegen))

If the namespace-scoped static variable is unreferenced from inline
functions, that's fine - such as the iostreams global initializer.

I'll send a CR to move these definitions out of line.

On Thu, Nov 9, 2017 at 12:30 AM Manuel Klimek <klimek at google.com> wrote:

> On Thu, Nov 9, 2017 at 12:43 AM David Blaikie <dblaikie at gmail.com> wrote:
>
>> Hey Manuel,
>>
>> In an effort to apply Modular Code Generation to Clang internally, I came
>> across the fact that this header contains a bunch of internal linkage
>> variables. (now, maybe modular code generation should be compatible with
>> internal linkage namespace-scoped variables... I'm looking into that)
>>
>> These variables technically create ODR violations any time they're
>> ODR-used in another inline function used in more than one translation unit.
>>
>> Is there a good way we could fix this header so it doesn't create ODR
>> violations (hopefully by not containing internal linkage entities)? I mean
>> one simple solution is to declare all these things in a header and define
>> them out of line. Since they have no actual state, that's probably pretty
>> low-cost except for a lot of duplication. I'm happy to use a .def/.inc file
>> to help remove a bunch of that duplication, if useful.
>>
>
> I remember having that argument a long time ago with somebody (perhaps Sam
> (cc'ed)?)
>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20171113/0aa7dce7/attachment.html>


More information about the cfe-dev mailing list