[cfe-dev] How do I try out C++ modules with clang?

[Richard Smith]

On Wed, Oct 22, 2014 at 3:22 AM, Stephen Kelly <steveire at gmail.com> wrote:

> Sean Silva <chisophugis at ...> writes:
>
> > Stephen, thanks for being a brave guinea pig here :)
>
> No problem!
>
> With the define I get more errors of the form:
>
> $ clang++ -E -fmodules -fmodules-cache-path=cache -D_USE_EXTENDED_LOCALES_
> test.cpp
> # 1 "test.cpp"
> # 1 "<built-in>" 1
> # 1 "<built-in>" 3
> # 325 "<built-in>" 3
> # 1 "<command line>" 1
> # 1 "<built-in>" 2
> # 1 "test.cpp" 2
> While building module 'std' imported from test.cpp:6:
> While building module 'Darwin' imported from
> /Users/ske/dev/prefix/bin/../include/c++/v1/__config:23:
> In file included from <module-includes>:3:
> In file included from /usr/include/ctype.h:384:
> /usr/include/xlocale/_ctype.h:35:50: error: unknown type name 'locale_t'
> unsigned long           ___runetype_l(__darwin_ct_rune_t, locale_t);
>                                                           ^
> /usr/include/xlocale/_ctype.h:36:53: error: unknown type name 'locale_t'
> __darwin_ct_rune_t      ___tolower_l(__darwin_ct_rune_t, locale_t);
>                                                          ^
>
>
> Actually I think I hit similar errors from files in /usr/include when I
> tried this a few weeks ago on linux, and I think my solution was to add a
> modulemap in /usr/include for a few things.


If you don't modularize bottom-up, the problems you're most likely to run
into are submodule visibility problems. Essentially, when a top-level
module has multiple submodules which try to textually include the same file
(and that file has include guards), only the first submodule to include
that file actually includes its contents (for the rest of them, the include
guards prevent repeated inclusion), so only that first submodule ends up
owning the header's contents. The result is that you can no longer rely on
indirect textual #includes to bring in file contents.

One way to avoid the problem is to avoid using submodules (Sean did this in
some of his experiments, and got some good results). Another way is to
properly modularize bottom-up (which means starting by fixing the module
maps and modularization of your system headers). We've also been discussing
ways that Clang could make this transparent by changing its submodules
model (so that multiple submodules of the same module *could*, in effect,
textually include the same source file).

I'll check that in a few days.
>
> This patch allows me to build the libcxx module:
>
> diff --git a/include/ios b/include/ios
> index ff79998..e5dc654 100644
> --- a/include/ios
> +++ b/include/ios
> @@ -213,6 +213,7 @@ storage-class-specifier const error_category&
> iostream_category() noexcept;
>
>  #include <__config>
>  #include <iosfwd>
> +#include <cstdlib>
>  #include <__locale>
>  #include <system_error>
>
>
> Though this stuff is very fiddly, and I have not yet grokked the whole
> connection/problem between modules and defines (I haven't passed the 'it
> basically works' barrier yet in order to grok that :) ), so I don't know if
> the above patch is the right approach.
>
> I am surprised that this problem has survived as I thought it would be an
> obvious "step 1" for anyone trying modules on mac. I guess either it's been
> tested so far on a different kind of system, or whoever added the modulemap
> for libcxx only tested it on linux. A unit test could be added in libcxx
> which attempts to build a module for it, right?


As far as I know, the libc++ (and LLVM and Clang) module maps have only
been successfully used on Linux.  I don't know whether the problems on Mac
are from a combination of subtly-incorrect module maps and non-modular
system headers, or are caused by Clang bugs (or both).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141022/45b88793/attachment.html>