[cfe-dev] Clang Modules: modularization of standard headers required?

[Dmitry Panin via cfe-dev]

>
> 1) If you don't modularize STL, then you just won't get any
> performance benefits when parsing the STL headers. Also some headers
> are sometimes incompatible with modules unless they're in their own
> [sub]module. E.g. you could have a header that is doing `class vector
> { MEM_TYPE a; }` and in one inclusion context we have `#define
> MEM_TYPE long` and in another `#define MEM_TYPE unsigned`. This breaks
> ODR checking but usually is prevented by modularizing the header that
> contains `vector`.
>

1) Yes, I understand that clang would still need to parse STL headers for
each TU unless they are coming from modules. Apparently when I try to use
modules on STL it fails with the similar ODR error but now on glibc and
kernel headers and then exposes a lot more errors on our codebase itself.
I would like transition to modules to be more incremental. It's fine to be
initially without performance benefits.
But if it's indeed incompatibility like you mentioned then it doesn't seem
to be the other way.



> 2)  It's probably not a regression, but IIRC this ODR check that
> recognizes the issue was introduced between those two revisions.
> Either it's a code issue like in my example above or it's a bug in
> this check. Try filing a bug report and you can usually workaround for
> now by modularizing those headers.
>

Just to confirm my understanding: if vector definitions are exactly the
same (even coming from different modules) then this ODR check shouldn't be
triggering, right?
I'll double check what's happening and file a bug if that's the issue with
the check.

Thanks for the pointers to filesystem overlays! I wasn't aware of such
mechanism.


-- 
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170701/d5bfbaf7/attachment.html>