[cfe-dev] Clang Modules: modularization of standard headers required?
Raphael Isemann via cfe-dev
cfe-dev at lists.llvm.org
Sat Jul 1 12:18:22 PDT 2017
2017-07-01 20:58 GMT+02:00 Dmitry Panin <pank.dm at gmail.com>:
>> 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.
Sounds about right. In your case it's either that that the definition
depends on the inclusion context of stl_vector.h or the ODR checking
has a bug.
As you're anyway building clang from source it seems, you could try
going to this line where we print the error
(https://github.com/llvm-mirror/clang/blob/1124518852a283a657d709877b9b474f1fc7e5fc/lib/Serialization/ASTReader.cpp#L9383
) and add
```
FirstDecl->dumpColor();
SecondDecl->dumpColor();
```
and then recompile and retry. Then you also get the AST of the vector
decl printed by clang on stderr (which is much more useful to debug).
> Thanks for the pointers to filesystem overlays! I wasn't aware of such
> mechanism.
>
>
> --
> Dmitry
More information about the cfe-dev
mailing list