Re: [libcxx] r249738 - Split out of .

[Richard Smith via cfe-commits]

Committed as r285152.

On Tue, Oct 25, 2016 at 3:09 PM, Richard Smith 
wrote:

> Missed one change from the test suite:
>
> Index: test/Modules/cstd.m
> ===
> --- test/Modules/cstd.m (revision 285117)
> +++ test/Modules/cstd.m (working copy)
> @@ -1,5 +1,5 @@
>  // RUN: rm -rf %t
> -// RUN: %clang_cc1 -fsyntax-only -isystem %S/Inputs/System/usr/include
> -ffreestanding -fmodules -fimplicit-module-maps -fmodules-cache-path=%t
> -D__need_wint_t -Werror=implicit-function-declaration %s
> +// RUN: %clang_cc1 -fsyntax-only -internal-isystem
> %S/Inputs/System/usr/include -fmodules -fimplicit-module-maps
> -fmodules-cache-path=%t -D__need_wint_t -Werror=implicit-function-declaration
> %s
>
>  @import uses_other_constants;
>  const double other_value = DBL_MAX;
>
>
> On Tue, Oct 25, 2016 at 2:56 PM, Richard Smith 
> wrote:
>
>> This was a thinko on my part: clang's builtin headers include_next the
>> system headers, not the other way around, so the system headers should be
>> implicitly textual, not clang's headers. This patch fixes the problem for
>> me with glibc. Does this help for Darwin too?
>>
>> On Tue, Oct 25, 2016 at 2:01 PM, Richard Smith 
>> wrote:
>>
>>> On Mon, Oct 24, 2016 at 4:58 PM, Bruno Cardoso Lopes via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 On Mon, Oct 24, 2016 at 4:17 PM, Richard Smith 
 wrote:
 > On Mon, Oct 24, 2016 at 3:30 PM, Bruno Cardoso Lopes
 >  wrote:
 >>
 >> > Sure, go ahead.
 >>
 >> I committed in r284797 and r284801 (libcxx). There's one minor issue
 >> I've found: the changes for the builtins affecting non submodule
 local
 >> visibility broke current users of plain "-fmodules" against our
 >> frameworks in public SDKs, in 10.11 & 10.12. I've attached a patch to
 >> work around that for the time being: make the new behavior dependent
 >> on local vis. Can you take a look?
 >
 >
 > What's the nature of the breakage? Generally I'd be fine with your
 patch,
 > but I wonder if there's something better we could do here.

 I haven't entirely isolated the problem, but they are all related to
 definitions from stdint.h. In one example below, uint32_t doesn't
 leak, requiring an explicit "#include " to make it work.

 -- example.m
 #import 
 --
 $ clang -arch x86_64 -isysroot
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.
 platform/Developer/SDKs/MacOSX10.12.sdk
 -fmodules-cache-path=tmpcache example.m -E -o /dev/null  -fmodules

 While building module 'IOKit' imported from example.m:1:
 In file included from :2:
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.
 platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frame
 works/IOKit.framework/Headers/IODataQueueClient.h:62:71:
 error: de
   'Darwin.POSIX._types._uint32_t' before it is required
 IOReturn IODataQueueDequeue(IODataQueueMemory *dataQueue, void *data,
 uint32_t *dataSize);
   ^
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.
 platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/_types/_
 uint32_t.h:31:22:
 note: previous declaration is here
 typedef unsigned int uint32_t;
  ^
 bot.m:1:9: fatal error: could not build module 'IOKit'
 #import 
  ~~~^
>>>
>>>
>>> This change also broke local submodule visibility builds with modular
>>> glibc (see PR30778 for details). I have an idea for how to fix this;
>>> running it through bootstrap now.
>>>
>>> >> > Hmm. Ideally, we should try to pick something that captures the
 spirit
 >> > of
 >> > "only non-modular headers and headers from used modules".
 Something like
 >> > "ignore_modules_not_declared_used", but less wordy?
 >>
 >> Right. It's gonna be hard to shrink this to a meaningful short name.
 >> What about a more generic "no_escape"?  "no_undeclared_headers"?
 >
 >
 > Hmm. Maybe we could allow the existing [exhaustive] attribute to be
 > specified on a use-declaration:
 >
 >   use [exhaustive] a, b, c

 I don't understand, the 'Darwin' module map doesn't use the 'use'
 keyword in any of its modules, how do you suggest we would use that to
 express the 'ignore_modules_not_declared_used' idea?
>>>
>>>
>>> Hah, right, this would only work if your module has dependencies. Maybe
>>> an [exhaustive_uses] attribute on the module itself then?
>>>
>>
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Richard Smith via cfe-commits]

Missed one change from the test suite:

Index: test/Modules/cstd.m
===
--- test/Modules/cstd.m (revision 285117)
+++ test/Modules/cstd.m (working copy)
@@ -1,5 +1,5 @@
 // RUN: rm -rf %t
-// RUN: %clang_cc1 -fsyntax-only -isystem %S/Inputs/System/usr/include
-ffreestanding -fmodules -fimplicit-module-maps -fmodules-cache-path=%t
-D__need_wint_t -Werror=implicit-function-declaration %s
+// RUN: %clang_cc1 -fsyntax-only -internal-isystem
%S/Inputs/System/usr/include -fmodules -fimplicit-module-maps
-fmodules-cache-path=%t -D__need_wint_t
-Werror=implicit-function-declaration %s

 @import uses_other_constants;
 const double other_value = DBL_MAX;


On Tue, Oct 25, 2016 at 2:56 PM, Richard Smith 
wrote:

> This was a thinko on my part: clang's builtin headers include_next the
> system headers, not the other way around, so the system headers should be
> implicitly textual, not clang's headers. This patch fixes the problem for
> me with glibc. Does this help for Darwin too?
>
> On Tue, Oct 25, 2016 at 2:01 PM, Richard Smith 
> wrote:
>
>> On Mon, Oct 24, 2016 at 4:58 PM, Bruno Cardoso Lopes via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> On Mon, Oct 24, 2016 at 4:17 PM, Richard Smith 
>>> wrote:
>>> > On Mon, Oct 24, 2016 at 3:30 PM, Bruno Cardoso Lopes
>>> >  wrote:
>>> >>
>>> >> > Sure, go ahead.
>>> >>
>>> >> I committed in r284797 and r284801 (libcxx). There's one minor issue
>>> >> I've found: the changes for the builtins affecting non submodule local
>>> >> visibility broke current users of plain "-fmodules" against our
>>> >> frameworks in public SDKs, in 10.11 & 10.12. I've attached a patch to
>>> >> work around that for the time being: make the new behavior dependent
>>> >> on local vis. Can you take a look?
>>> >
>>> >
>>> > What's the nature of the breakage? Generally I'd be fine with your
>>> patch,
>>> > but I wonder if there's something better we could do here.
>>>
>>> I haven't entirely isolated the problem, but they are all related to
>>> definitions from stdint.h. In one example below, uint32_t doesn't
>>> leak, requiring an explicit "#include " to make it work.
>>>
>>> -- example.m
>>> #import 
>>> --
>>> $ clang -arch x86_64 -isysroot
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.
>>> platform/Developer/SDKs/MacOSX10.12.sdk
>>> -fmodules-cache-path=tmpcache example.m -E -o /dev/null  -fmodules
>>>
>>> While building module 'IOKit' imported from example.m:1:
>>> In file included from :2:
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.
>>> platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/
>>> Frameworks/IOKit.framework/Headers/IODataQueueClient.h:62:71:
>>> error: de
>>>   'Darwin.POSIX._types._uint32_t' before it is required
>>> IOReturn IODataQueueDequeue(IODataQueueMemory *dataQueue, void *data,
>>> uint32_t *dataSize);
>>>   ^
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.
>>> platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/_types/_
>>> uint32_t.h:31:22:
>>> note: previous declaration is here
>>> typedef unsigned int uint32_t;
>>>  ^
>>> bot.m:1:9: fatal error: could not build module 'IOKit'
>>> #import 
>>>  ~~~^
>>
>>
>> This change also broke local submodule visibility builds with modular
>> glibc (see PR30778 for details). I have an idea for how to fix this;
>> running it through bootstrap now.
>>
>> >> > Hmm. Ideally, we should try to pick something that captures the
>>> spirit
>>> >> > of
>>> >> > "only non-modular headers and headers from used modules". Something
>>> like
>>> >> > "ignore_modules_not_declared_used", but less wordy?
>>> >>
>>> >> Right. It's gonna be hard to shrink this to a meaningful short name.
>>> >> What about a more generic "no_escape"?  "no_undeclared_headers"?
>>> >
>>> >
>>> > Hmm. Maybe we could allow the existing [exhaustive] attribute to be
>>> > specified on a use-declaration:
>>> >
>>> >   use [exhaustive] a, b, c
>>>
>>> I don't understand, the 'Darwin' module map doesn't use the 'use'
>>> keyword in any of its modules, how do you suggest we would use that to
>>> express the 'ignore_modules_not_declared_used' idea?
>>
>>
>> Hah, right, this would only work if your module has dependencies. Maybe
>> an [exhaustive_uses] attribute on the module itself then?
>>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Richard Smith via cfe-commits]

This was a thinko on my part: clang's builtin headers include_next the
system headers, not the other way around, so the system headers should be
implicitly textual, not clang's headers. This patch fixes the problem for
me with glibc. Does this help for Darwin too?

On Tue, Oct 25, 2016 at 2:01 PM, Richard Smith 
wrote:

> On Mon, Oct 24, 2016 at 4:58 PM, Bruno Cardoso Lopes via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> On Mon, Oct 24, 2016 at 4:17 PM, Richard Smith 
>> wrote:
>> > On Mon, Oct 24, 2016 at 3:30 PM, Bruno Cardoso Lopes
>> >  wrote:
>> >>
>> >> > Sure, go ahead.
>> >>
>> >> I committed in r284797 and r284801 (libcxx). There's one minor issue
>> >> I've found: the changes for the builtins affecting non submodule local
>> >> visibility broke current users of plain "-fmodules" against our
>> >> frameworks in public SDKs, in 10.11 & 10.12. I've attached a patch to
>> >> work around that for the time being: make the new behavior dependent
>> >> on local vis. Can you take a look?
>> >
>> >
>> > What's the nature of the breakage? Generally I'd be fine with your
>> patch,
>> > but I wonder if there's something better we could do here.
>>
>> I haven't entirely isolated the problem, but they are all related to
>> definitions from stdint.h. In one example below, uint32_t doesn't
>> leak, requiring an explicit "#include " to make it work.
>>
>> -- example.m
>> #import 
>> --
>> $ clang -arch x86_64 -isysroot
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.
>> platform/Developer/SDKs/MacOSX10.12.sdk
>> -fmodules-cache-path=tmpcache example.m -E -o /dev/null  -fmodules
>>
>> While building module 'IOKit' imported from example.m:1:
>> In file included from :2:
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.
>> platform/Developer/SDKs/MacOSX10.12.sdk/System/Library
>> /Frameworks/IOKit.framework/Headers/IODataQueueClient.h:62:71:
>> error: de
>>   'Darwin.POSIX._types._uint32_t' before it is required
>> IOReturn IODataQueueDequeue(IODataQueueMemory *dataQueue, void *data,
>> uint32_t *dataSize);
>>   ^
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.
>> platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/_
>> types/_uint32_t.h:31:22:
>> note: previous declaration is here
>> typedef unsigned int uint32_t;
>>  ^
>> bot.m:1:9: fatal error: could not build module 'IOKit'
>> #import 
>>  ~~~^
>
>
> This change also broke local submodule visibility builds with modular
> glibc (see PR30778 for details). I have an idea for how to fix this;
> running it through bootstrap now.
>
> >> > Hmm. Ideally, we should try to pick something that captures the spirit
>> >> > of
>> >> > "only non-modular headers and headers from used modules". Something
>> like
>> >> > "ignore_modules_not_declared_used", but less wordy?
>> >>
>> >> Right. It's gonna be hard to shrink this to a meaningful short name.
>> >> What about a more generic "no_escape"?  "no_undeclared_headers"?
>> >
>> >
>> > Hmm. Maybe we could allow the existing [exhaustive] attribute to be
>> > specified on a use-declaration:
>> >
>> >   use [exhaustive] a, b, c
>>
>> I don't understand, the 'Darwin' module map doesn't use the 'use'
>> keyword in any of its modules, how do you suggest we would use that to
>> express the 'ignore_modules_not_declared_used' idea?
>
>
> Hah, right, this would only work if your module has dependencies. Maybe an
> [exhaustive_uses] attribute on the module itself then?
>
Index: lib/Lex/ModuleMap.cpp
===
--- lib/Lex/ModuleMap.cpp   (revision 285117)
+++ lib/Lex/ModuleMap.cpp   (working copy)
@@ -1881,16 +1881,20 @@
   Module::Header H = {RelativePathName.str(), File};
   Map.excludeHeader(ActiveModule, H);
 } else {
-  // If there is a builtin counterpart to this file, add it now as a 
textual
-  // header, so it can be #include_next'd by the wrapper header, and can
-  // receive macros from the wrapper header.
+  // If there is a builtin counterpart to this file, add it now so it can
+  // wrap the system header.
   if (BuiltinFile) {
 // FIXME: Taking the name from the FileEntry is unstable and can give
 // different results depending on how we've previously named that file
 // in this build.
 Module::Header H = { BuiltinFile->getName(), BuiltinFile };
-Map.addHeader(ActiveModule, H, ModuleMap::ModuleHeaderRole(
-   Role | ModuleMap::TextualHeader));
+Map.addHeader(ActiveModule, H, Role);
+
+// If we have both a builtin and system version of the file, the
+// builtin version may want to inject macros into the system header, so
+// force the system header to be treated as a textual header in this
+

Re: [libcxx] r249738 - Split out of .

[Richard Smith via cfe-commits]

On Mon, Oct 24, 2016 at 4:58 PM, Bruno Cardoso Lopes via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Mon, Oct 24, 2016 at 4:17 PM, Richard Smith 
> wrote:
> > On Mon, Oct 24, 2016 at 3:30 PM, Bruno Cardoso Lopes
> >  wrote:
> >>
> >> > Sure, go ahead.
> >>
> >> I committed in r284797 and r284801 (libcxx). There's one minor issue
> >> I've found: the changes for the builtins affecting non submodule local
> >> visibility broke current users of plain "-fmodules" against our
> >> frameworks in public SDKs, in 10.11 & 10.12. I've attached a patch to
> >> work around that for the time being: make the new behavior dependent
> >> on local vis. Can you take a look?
> >
> >
> > What's the nature of the breakage? Generally I'd be fine with your patch,
> > but I wonder if there's something better we could do here.
>
> I haven't entirely isolated the problem, but they are all related to
> definitions from stdint.h. In one example below, uint32_t doesn't
> leak, requiring an explicit "#include " to make it work.
>
> -- example.m
> #import 
> --
> $ clang -arch x86_64 -isysroot
> /Applications/Xcode.app/Contents/Developer/Platforms/
> MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
> -fmodules-cache-path=tmpcache example.m -E -o /dev/null  -fmodules
>
> While building module 'IOKit' imported from example.m:1:
> In file included from :2:
> /Applications/Xcode.app/Contents/Developer/Platforms/
> MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/
> Library/Frameworks/IOKit.framework/Headers/IODataQueueClient.h:62:71:
> error: de
>   'Darwin.POSIX._types._uint32_t' before it is required
> IOReturn IODataQueueDequeue(IODataQueueMemory *dataQueue, void *data,
> uint32_t *dataSize);
>   ^
> /Applications/Xcode.app/Contents/Developer/Platforms/
> MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/
> include/_types/_uint32_t.h:31:22:
> note: previous declaration is here
> typedef unsigned int uint32_t;
>  ^
> bot.m:1:9: fatal error: could not build module 'IOKit'
> #import 
>  ~~~^


This change also broke local submodule visibility builds with modular glibc
(see PR30778 for details). I have an idea for how to fix this; running it
through bootstrap now.

>> > Hmm. Ideally, we should try to pick something that captures the spirit
> >> > of
> >> > "only non-modular headers and headers from used modules". Something
> like
> >> > "ignore_modules_not_declared_used", but less wordy?
> >>
> >> Right. It's gonna be hard to shrink this to a meaningful short name.
> >> What about a more generic "no_escape"?  "no_undeclared_headers"?
> >
> >
> > Hmm. Maybe we could allow the existing [exhaustive] attribute to be
> > specified on a use-declaration:
> >
> >   use [exhaustive] a, b, c
>
> I don't understand, the 'Darwin' module map doesn't use the 'use'
> keyword in any of its modules, how do you suggest we would use that to
> express the 'ignore_modules_not_declared_used' idea?


Hah, right, this would only work if your module has dependencies. Maybe an
[exhaustive_uses] attribute on the module itself then?
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Bruno Cardoso Lopes via cfe-commits]

On Mon, Oct 24, 2016 at 4:17 PM, Richard Smith  wrote:
> On Mon, Oct 24, 2016 at 3:30 PM, Bruno Cardoso Lopes
>  wrote:
>>
>> > Sure, go ahead.
>>
>> I committed in r284797 and r284801 (libcxx). There's one minor issue
>> I've found: the changes for the builtins affecting non submodule local
>> visibility broke current users of plain "-fmodules" against our
>> frameworks in public SDKs, in 10.11 & 10.12. I've attached a patch to
>> work around that for the time being: make the new behavior dependent
>> on local vis. Can you take a look?
>
>
> What's the nature of the breakage? Generally I'd be fine with your patch,
> but I wonder if there's something better we could do here.

I haven't entirely isolated the problem, but they are all related to
definitions from stdint.h. In one example below, uint32_t doesn't
leak, requiring an explicit "#include " to make it work.

-- example.m
#import 
--
$ clang -arch x86_64 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
-fmodules-cache-path=tmpcache example.m -E -o /dev/null  -fmodules

While building module 'IOKit' imported from example.m:1:
In file included from :2:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/IOKit.framework/Headers/IODataQueueClient.h:62:71:
error: de
  'Darwin.POSIX._types._uint32_t' before it is required
IOReturn IODataQueueDequeue(IODataQueueMemory *dataQueue, void *data,
uint32_t *dataSize);
  ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/_types/_uint32_t.h:31:22:
note: previous declaration is here
typedef unsigned int uint32_t;
 ^
bot.m:1:9: fatal error: could not build module 'IOKit'
#import 
 ~~~^

>
>> > Hmm. Ideally, we should try to pick something that captures the spirit
>> > of
>> > "only non-modular headers and headers from used modules". Something like
>> > "ignore_modules_not_declared_used", but less wordy?
>>
>> Right. It's gonna be hard to shrink this to a meaningful short name.
>> What about a more generic "no_escape"?  "no_undeclared_headers"?
>
>
> Hmm. Maybe we could allow the existing [exhaustive] attribute to be
> specified on a use-declaration:
>
>   use [exhaustive] a, b, c

I don't understand, the 'Darwin' module map doesn't use the 'use'
keyword in any of its modules, how do you suggest we would use that to
express the 'ignore_modules_not_declared_used' idea?



-- 
Bruno Cardoso Lopes
http://www.brunocardoso.cc
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Richard Smith via cfe-commits]

On Mon, Oct 24, 2016 at 3:30 PM, Bruno Cardoso Lopes <
bruno.card...@gmail.com> wrote:

> > Sure, go ahead.
>
> I committed in r284797 and r284801 (libcxx). There's one minor issue
> I've found: the changes for the builtins affecting non submodule local
> visibility broke current users of plain "-fmodules" against our
> frameworks in public SDKs, in 10.11 & 10.12. I've attached a patch to
> work around that for the time being: make the new behavior dependent
> on local vis. Can you take a look?


What's the nature of the breakage? Generally I'd be fine with your patch,
but I wonder if there's something better we could do here.

> Hmm. Ideally, we should try to pick something that captures the spirit of
> > "only non-modular headers and headers from used modules". Something like
> > "ignore_modules_not_declared_used", but less wordy?
>
> Right. It's gonna be hard to shrink this to a meaningful short name.
> What about a more generic "no_escape"?  "no_undeclared_headers"?
>

Hmm. Maybe we could allow the existing [exhaustive] attribute to be
specified on a use-declaration:

  use [exhaustive] a, b, c
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Bruno Cardoso Lopes via cfe-commits]

> Sure, go ahead.

I committed in r284797 and r284801 (libcxx). There's one minor issue
I've found: the changes for the builtins affecting non submodule local
visibility broke current users of plain "-fmodules" against our
frameworks in public SDKs, in 10.11 & 10.12. I've attached a patch to
work around that for the time being: make the new behavior dependent
on local vis. Can you take a look?

> Hmm. Ideally, we should try to pick something that captures the spirit of
> "only non-modular headers and headers from used modules". Something like
> "ignore_modules_not_declared_used", but less wordy?

Right. It's gonna be hard to shrink this to a meaningful short name.
What about a more generic "no_escape"?  "no_undeclared_headers"?

Thanks again,

-- 
Bruno Cardoso Lopes
http://www.brunocardoso.cc


0001-Modules-Fix-side-effect-of-built-in-changes-from-r28.patch
Description: Binary data
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Richard Smith via cfe-commits]

On Mon, Oct 17, 2016 at 3:31 PM, Manman via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
>
> > On Oct 17, 2016, at 2:11 PM, Bruno Cardoso Lopes via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
> >
> > Hi,
> >
> > On Fri, Oct 14, 2016 at 3:09 PM, Richard Smith 
> wrote:
> >> On Fri, Oct 14, 2016 at 11:44 AM, Bruno Cardoso Lopes
> >>  wrote:
> >>>
> >>> Hi Richard,
> >>>
> >>> I have a patch on top of your suggested patch from a year ago, that
> >>> break the cyclic dependency we're seeing, with this (and a few changes
> >>> to the SDK) we can bootstrap clang with submodule local visibility on
> >>> darwin. I've attached the patch with a reduced, standalone testcase
> >>> that doesn't depend on the SDK. The issues that are not covered by
> >>> your patch, that I cover in mine, are related to built-in and textual
> >>> headers: they can be found in paths where they don't map to any
> >>> modules, triggering other cycles. I fix that by looking further to
> >>> find a matching module for the header in question, instead the first
> >>> found header in header search.
> >>
> >>
> >> It looks like the 0002 patch is working around a bug in the 0001 patch:
> with
> >> 0001 applied, a module with [no_undeclared_includes] can still include a
> >> textual header from another module on which it doesn't declare a
> dependency
> >> (in the testcase, the libc module is incorrectly permitted to include
> the
> >> textual header  from libc++). Rather than preferring
> non-modular
> >> headers over modular headers as the 0002 patch does, I wonder if the
> issue
> >> could instead be resolved by fixing that apparent bug.
> >
> > Thanks for the fast answer and for the new patch :-)
> > My intend with 0002 was actually to prefer modular headers instead of
> > non-modular, but fallback to the later in case none is found.
> >
> >> I gave that a go; the result is attached. I also had to change the way
> we
> >> handle builtin headers -- instead of implicitly including (for
> instance) the
> >> builtin  as a modular header in any module that provides its
> own
> >> , I now only include it as a textual header (this also lets
> us use
> >> the same approach for this case whether or not we're using local
> submodule
> >> visibility).
>
> @Richard,
>
> I wonder why (prior to your patch) we need to use a different approach for
> builtin headers with local submodule visibility.
>

I don't think we did (see the FIXME I deleted suggesting to use the local
submodule visibiltiy logic in all cases).

Thanks,
>
> >> That exposed a couple of testcases that were (unreasonably, in
> >> my opinion) failing to include_next the real builtin header from their
> >> wrapper header.
> >
> > I'm curious about these, are they from clang tests?
> >
> >> The attached patch causes your testcase to pass; I'd be interested to
> know
> >> if it works in practice on Darwin.
> >
> > It works for building the Darwin module, but failed for "#include
> > " on darwin (which was working under 0001+0002 patch):
> >
> > While building module 'std' imported from all-headers.cpp:1:
> > While building module 'Darwin' imported from
> > /clang-install/include/c++/v1/string.h:61:
> > In file included from :422:
> > In file included from /SDK/MacOSX10.12.sdk/usr/include/mach/mach.h:67:
> > In file included from /SDK/MacOSX10.12.sdk/usr/
> include/mach/mach_interface.h:42:
> > In file included from /SDK/MacOSX10.12.sdk/usr/
> include/mach/clock_priv.h:6:
> > /clang-install/include/c++/v1/string.h:74:7: error: redefinition of
> > '__libcpp_strchr'
> > char* __libcpp_strchr(const char* __s, int __c) {return
> > (char*)strchr(__s, __c);}
> >  ^
> > /clang-install/include/c++/v1/string.h:74:7: note: previous definition
> is here
>
> @Bruno,
>
> Can you try "-fdiagnostics-show-note-include-stack” so we know the other
> path that leads to string.h?
>
> Manman
>
> > char* __libcpp_strchr(const char* __s, int __c) {return
> > (char*)strchr(__s, __c);}
> >  ^
> > While building module 'std' imported from all-headers.cpp:1:
> > While building module 'Darwin' imported from
> > /clang-install/include/c++/v1/string.h:61:
> > In file included from :422:
> > In file included from /SDK/MacOSX10.12.sdk/usr/include/mach/mach.h:67:
> > In file included from /SDK/MacOSX10.12.sdk/usr/
> include/mach/mach_interface.h:42:
> > In file included from /SDK/MacOSX10.12.sdk/usr/
> include/mach/clock_priv.h:6:
> > /clang-install/include/c++/v1/string.h:76:13: error: redefinition of
> 'strchr'
> > const char* strchr(const char* __s, int __c) {return
> __libcpp_strchr(__s, __c);}
> >^
> > /clang-install/include/c++/v1/string.h:76:13: note: previous definition
> is here
> > const char* strchr(const char* __s, int __c) {return
> __libcpp_strchr(__s, __c);}
> >^
> > <...>
> > While building module 'std' imported from all-headers.cpp:1:
> > In file included from :1:
> > In file included from 

Re: [libcxx] r249738 - Split out of .

[Richard Smith via cfe-commits]

On Tue, Oct 18, 2016 at 4:30 PM, Bruno Cardoso Lopes <
bruno.card...@gmail.com> wrote:

> Hi Richard,
>
> Turns out that the redefinition error was caused because libc++
> modulemap lacked a module for its "string.h", and therefore it would
> be textually included in more than one module, yielding the error.
>
> With the attached patch for libc++ modulemap (extracted from parts of
> a modulemap you previously attached to the thread) + your patch, I can
> successfully compile Darwin and selfhost clang with submodule local
> visibility.


Awesome.


> I can also upstream the patches for you in case your too
> busy, let me know.
>

Sure, go ahead.


> One minor note: the keyword name 'no_undeclared_includes' sounds a bit
> confusing, how about 'direct_uses_only', or something along these
> lines?
>

Hmm. Ideally, we should try to pick something that captures the spirit of
"only non-modular headers and headers from used modules". Something like
"ignore_modules_not_declared_used", but less wordy?


> Thanks,
>
> On Mon, Oct 17, 2016 at 3:59 PM, Bruno Cardoso Lopes
>  wrote:
> >> @Bruno,
> >>
> >> Can you try "-fdiagnostics-show-note-include-stack” so we know the
> other path that leads to string.h?
> >
> > Attached the complete error log (this snippet won't help without full
> > context anyway)
>
> --
> Bruno Cardoso Lopes
> http://www.brunocardoso.cc
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Bruno Cardoso Lopes via cfe-commits]

Hi Richard,

Turns out that the redefinition error was caused because libc++
modulemap lacked a module for its "string.h", and therefore it would
be textually included in more than one module, yielding the error.

With the attached patch for libc++ modulemap (extracted from parts of
a modulemap you previously attached to the thread) + your patch, I can
successfully compile Darwin and selfhost clang with submodule local
visibility. I can also upstream the patches for you in case your too
busy, let me know.

One minor note: the keyword name 'no_undeclared_includes' sounds a bit
confusing, how about 'direct_uses_only', or something along these
lines?

Thanks,

On Mon, Oct 17, 2016 at 3:59 PM, Bruno Cardoso Lopes
 wrote:
>> @Bruno,
>>
>> Can you try "-fdiagnostics-show-note-include-stack” so we know the other 
>> path that leads to string.h?
>
> Attached the complete error log (this snippet won't help without full
> context anyway)

-- 
Bruno Cardoso Lopes
http://www.brunocardoso.cc


0001-ModuleMap-Add-module-entries-for-non-modular-headers.patch
Description: Binary data
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Bruno Cardoso Lopes via cfe-commits]

> @Bruno,
>
> Can you try "-fdiagnostics-show-note-include-stack” so we know the other path 
> that leads to string.h?

Attached the complete error log (this snippet won't help without full
context anyway)



-- 
Bruno Cardoso Lopes
http://www.brunocardoso.cc


output.log
Description: Binary data
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Manman via cfe-commits]

> On Oct 17, 2016, at 2:11 PM, Bruno Cardoso Lopes via cfe-commits 
>  wrote:
> 
> Hi,
> 
> On Fri, Oct 14, 2016 at 3:09 PM, Richard Smith  wrote:
>> On Fri, Oct 14, 2016 at 11:44 AM, Bruno Cardoso Lopes
>>  wrote:
>>> 
>>> Hi Richard,
>>> 
>>> I have a patch on top of your suggested patch from a year ago, that
>>> break the cyclic dependency we're seeing, with this (and a few changes
>>> to the SDK) we can bootstrap clang with submodule local visibility on
>>> darwin. I've attached the patch with a reduced, standalone testcase
>>> that doesn't depend on the SDK. The issues that are not covered by
>>> your patch, that I cover in mine, are related to built-in and textual
>>> headers: they can be found in paths where they don't map to any
>>> modules, triggering other cycles. I fix that by looking further to
>>> find a matching module for the header in question, instead the first
>>> found header in header search.
>> 
>> 
>> It looks like the 0002 patch is working around a bug in the 0001 patch: with
>> 0001 applied, a module with [no_undeclared_includes] can still include a
>> textual header from another module on which it doesn't declare a dependency
>> (in the testcase, the libc module is incorrectly permitted to include the
>> textual header  from libc++). Rather than preferring non-modular
>> headers over modular headers as the 0002 patch does, I wonder if the issue
>> could instead be resolved by fixing that apparent bug.
> 
> Thanks for the fast answer and for the new patch :-)
> My intend with 0002 was actually to prefer modular headers instead of
> non-modular, but fallback to the later in case none is found.
> 
>> I gave that a go; the result is attached. I also had to change the way we
>> handle builtin headers -- instead of implicitly including (for instance) the
>> builtin  as a modular header in any module that provides its own
>> , I now only include it as a textual header (this also lets us use
>> the same approach for this case whether or not we're using local submodule
>> visibility).

@Richard,

I wonder why (prior to your patch) we need to use a different approach for 
builtin headers with local submodule visibility.

Thanks,

>> That exposed a couple of testcases that were (unreasonably, in
>> my opinion) failing to include_next the real builtin header from their
>> wrapper header.
> 
> I'm curious about these, are they from clang tests?
> 
>> The attached patch causes your testcase to pass; I'd be interested to know
>> if it works in practice on Darwin.
> 
> It works for building the Darwin module, but failed for "#include
> " on darwin (which was working under 0001+0002 patch):
> 
> While building module 'std' imported from all-headers.cpp:1:
> While building module 'Darwin' imported from
> /clang-install/include/c++/v1/string.h:61:
> In file included from :422:
> In file included from /SDK/MacOSX10.12.sdk/usr/include/mach/mach.h:67:
> In file included from 
> /SDK/MacOSX10.12.sdk/usr/include/mach/mach_interface.h:42:
> In file included from /SDK/MacOSX10.12.sdk/usr/include/mach/clock_priv.h:6:
> /clang-install/include/c++/v1/string.h:74:7: error: redefinition of
> '__libcpp_strchr'
> char* __libcpp_strchr(const char* __s, int __c) {return
> (char*)strchr(__s, __c);}
>  ^
> /clang-install/include/c++/v1/string.h:74:7: note: previous definition is here

@Bruno,

Can you try "-fdiagnostics-show-note-include-stack” so we know the other path 
that leads to string.h?

Manman

> char* __libcpp_strchr(const char* __s, int __c) {return
> (char*)strchr(__s, __c);}
>  ^
> While building module 'std' imported from all-headers.cpp:1:
> While building module 'Darwin' imported from
> /clang-install/include/c++/v1/string.h:61:
> In file included from :422:
> In file included from /SDK/MacOSX10.12.sdk/usr/include/mach/mach.h:67:
> In file included from 
> /SDK/MacOSX10.12.sdk/usr/include/mach/mach_interface.h:42:
> In file included from /SDK/MacOSX10.12.sdk/usr/include/mach/clock_priv.h:6:
> /clang-install/include/c++/v1/string.h:76:13: error: redefinition of 'strchr'
> const char* strchr(const char* __s, int __c) {return __libcpp_strchr(__s, 
> __c);}
>^
> /clang-install/include/c++/v1/string.h:76:13: note: previous definition is 
> here
> const char* strchr(const char* __s, int __c) {return __libcpp_strchr(__s, 
> __c);}
>^
> <...>
> While building module 'std' imported from all-headers.cpp:1:
> In file included from :1:
> In file included from /clang-install/include/c++/v1/algorithm:638:
> In file included from /clang-install/include/c++/v1/cstring:61:
> /clang-install/include/c++/v1/string.h:61:15: fatal error: could not
> build module 'Darwin'
> #include_next 
> ~^
> all-headers.cpp:1:10: fatal error: could not build module 'std'
> #include 
> ^
> 17 errors generated.
> 
> It looks like "#include_next " is poiting back to
> /clang-install/include/c++/v1/string.h
> 

Re: [libcxx] r249738 - Split out of .

[Bruno Cardoso Lopes via cfe-commits]

Hi,

On Fri, Oct 14, 2016 at 3:09 PM, Richard Smith  wrote:
> On Fri, Oct 14, 2016 at 11:44 AM, Bruno Cardoso Lopes
>  wrote:
>>
>> Hi Richard,
>>
>> I have a patch on top of your suggested patch from a year ago, that
>> break the cyclic dependency we're seeing, with this (and a few changes
>> to the SDK) we can bootstrap clang with submodule local visibility on
>> darwin. I've attached the patch with a reduced, standalone testcase
>> that doesn't depend on the SDK. The issues that are not covered by
>> your patch, that I cover in mine, are related to built-in and textual
>> headers: they can be found in paths where they don't map to any
>> modules, triggering other cycles. I fix that by looking further to
>> find a matching module for the header in question, instead the first
>> found header in header search.
>
>
> It looks like the 0002 patch is working around a bug in the 0001 patch: with
> 0001 applied, a module with [no_undeclared_includes] can still include a
> textual header from another module on which it doesn't declare a dependency
> (in the testcase, the libc module is incorrectly permitted to include the
> textual header  from libc++). Rather than preferring non-modular
> headers over modular headers as the 0002 patch does, I wonder if the issue
> could instead be resolved by fixing that apparent bug.

Thanks for the fast answer and for the new patch :-)
My intend with 0002 was actually to prefer modular headers instead of
non-modular, but fallback to the later in case none is found.

> I gave that a go; the result is attached. I also had to change the way we
> handle builtin headers -- instead of implicitly including (for instance) the
> builtin  as a modular header in any module that provides its own
> , I now only include it as a textual header (this also lets us use
> the same approach for this case whether or not we're using local submodule
> visibility). That exposed a couple of testcases that were (unreasonably, in
> my opinion) failing to include_next the real builtin header from their
> wrapper header.

I'm curious about these, are they from clang tests?

> The attached patch causes your testcase to pass; I'd be interested to know
> if it works in practice on Darwin.

It works for building the Darwin module, but failed for "#include
" on darwin (which was working under 0001+0002 patch):

While building module 'std' imported from all-headers.cpp:1:
While building module 'Darwin' imported from
/clang-install/include/c++/v1/string.h:61:
In file included from :422:
In file included from /SDK/MacOSX10.12.sdk/usr/include/mach/mach.h:67:
In file included from /SDK/MacOSX10.12.sdk/usr/include/mach/mach_interface.h:42:
In file included from /SDK/MacOSX10.12.sdk/usr/include/mach/clock_priv.h:6:
/clang-install/include/c++/v1/string.h:74:7: error: redefinition of
'__libcpp_strchr'
char* __libcpp_strchr(const char* __s, int __c) {return
(char*)strchr(__s, __c);}
  ^
/clang-install/include/c++/v1/string.h:74:7: note: previous definition is here
char* __libcpp_strchr(const char* __s, int __c) {return
(char*)strchr(__s, __c);}
  ^
While building module 'std' imported from all-headers.cpp:1:
While building module 'Darwin' imported from
/clang-install/include/c++/v1/string.h:61:
In file included from :422:
In file included from /SDK/MacOSX10.12.sdk/usr/include/mach/mach.h:67:
In file included from /SDK/MacOSX10.12.sdk/usr/include/mach/mach_interface.h:42:
In file included from /SDK/MacOSX10.12.sdk/usr/include/mach/clock_priv.h:6:
/clang-install/include/c++/v1/string.h:76:13: error: redefinition of 'strchr'
const char* strchr(const char* __s, int __c) {return __libcpp_strchr(__s, __c);}
^
/clang-install/include/c++/v1/string.h:76:13: note: previous definition is here
const char* strchr(const char* __s, int __c) {return __libcpp_strchr(__s, __c);}
^
<...>
While building module 'std' imported from all-headers.cpp:1:
In file included from :1:
In file included from /clang-install/include/c++/v1/algorithm:638:
In file included from /clang-install/include/c++/v1/cstring:61:
/clang-install/include/c++/v1/string.h:61:15: fatal error: could not
build module 'Darwin'
#include_next 
 ~^
all-headers.cpp:1:10: fatal error: could not build module 'std'
#include 
 ^
17 errors generated.

It looks like "#include_next " is poiting back to
/clang-install/include/c++/v1/string.h
FWIW, string.h is also in SDK/usr/include/string.h, under
Darwin.C.string module.
I'll get back to you with a small testcase once I'm able to reduce this.

Thanks!


-- 
Bruno Cardoso Lopes
http://www.brunocardoso.cc
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Richard Smith via cfe-commits]

On Fri, Oct 14, 2016 at 11:44 AM, Bruno Cardoso Lopes <
bruno.card...@gmail.com> wrote:

> Hi Richard,
>
> I have a patch on top of your suggested patch from a year ago, that
> break the cyclic dependency we're seeing, with this (and a few changes
> to the SDK) we can bootstrap clang with submodule local visibility on
> darwin. I've attached the patch with a reduced, standalone testcase
> that doesn't depend on the SDK. The issues that are not covered by
> your patch, that I cover in mine, are related to built-in and textual
> headers: they can be found in paths where they don't map to any
> modules, triggering other cycles. I fix that by looking further to
> find a matching module for the header in question, instead the first
> found header in header search.
>

It looks like the 0002 patch is working around a bug in the 0001 patch:
with 0001 applied, a module with [no_undeclared_includes] can still include
a textual header from another module on which it doesn't declare a
dependency (in the testcase, the libc module is incorrectly permitted to
include the textual header  from libc++). Rather than preferring
non-modular headers over modular headers as the 0002 patch does, I wonder
if the issue could instead be resolved by fixing that apparent bug.

I gave that a go; the result is attached. I also had to change the way we
handle builtin headers -- instead of implicitly including (for instance)
the builtin  as a modular header in any module that provides its
own , I now only include it as a textual header (this also lets
us use the same approach for this case whether or not we're using local
submodule visibility). That exposed a couple of testcases that were
(unreasonably, in my opinion) failing to include_next the real builtin
header from their wrapper header.

The attached patch causes your testcase to pass; I'd be interested to know
if it works in practice on Darwin.

Thanks!


> Can you take a look?
>
> Thanks,
>
>
> On Thu, Jul 28, 2016 at 3:55 PM, Adrian Prantl via cfe-commits
>  wrote:
> > +Bruno
> >
> > On Jul 27, 2016, at 11:58 PM, Nico Weber  wrote:
> >
> > I played with modules a bit today, and as far as I can tell this is still
> > broken. If this proves difficult to fix, should this change be reverted
> for
> > now? It breaks using modules on Darwin.
> >
> > On Sun, Mar 13, 2016 at 12:53 AM, Adrian Prantl via cfe-commits
> >  wrote:
> >>
> >> > On Mar 11, 2016, at 4:11 PM, Duncan P. N. Exon Smith
> >> >  wrote:
> >> >
> >> > Did anyone file a PR for this?
> >> >
> >>
> >> I filed PR 26928 - Prune the include path for modules
> >> https://llvm.org/bugs/show_bug.cgi?id=26928
> >> as a starting point.
> >>
> >> -- adrian
> >>
> >> ___
> >> cfe-commits mailing list
> >> cfe-commits@lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> >
> >
> >
> >
> > ___
> > cfe-commits mailing list
> > cfe-commits@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> >
>
>
>
> --
> Bruno Cardoso Lopes
> http://www.brunocardoso.cc
>
Index: include/clang/Basic/Module.h
===
--- include/clang/Basic/Module.h(revision 284181)
+++ include/clang/Basic/Module.h(working copy)
@@ -201,6 +201,10 @@
   /// built.
   unsigned ConfigMacrosExhaustive : 1;
 
+  /// \brief Whether files in this module can only include files from used
+  /// modules.
+  unsigned NoUndeclaredIncludes : 1;
+
   /// \brief Describes the visibility of the various names within a
   /// particular module.
   enum NameVisibilityKind {
Index: include/clang/Lex/HeaderSearch.h
===
--- include/clang/Lex/HeaderSearch.h(revision 284181)
+++ include/clang/Lex/HeaderSearch.h(working copy)
@@ -523,8 +523,10 @@
   /// \brief Retrieve the module that corresponds to the given file, if any.
   ///
   /// \param File The header that we wish to map to a module.
-  ModuleMap::KnownHeader findModuleForHeader(const FileEntry *File) const;
-  
+  /// \param AllowTextual Whether we want to find textual headers too.
+  ModuleMap::KnownHeader findModuleForHeader(const FileEntry *File,
+ bool AllowTextual = false) const;
+
   /// \brief Read the contents of the given module map file.
   ///
   /// \param File The module map file.
Index: include/clang/Lex/ModuleMap.h
===
--- include/clang/Lex/ModuleMap.h   (revision 284181)
+++ include/clang/Lex/ModuleMap.h   (working copy)
@@ -171,7 +171,8 @@
 
   /// \brief The set of attributes that can be attached to a module.
   struct Attributes {
-Attributes() : IsSystem(), IsExternC(), IsExhaustive() {}
+Attributes()
+: 

Re: [libcxx] r249738 - Split out of .

[Bruno Cardoso Lopes via cfe-commits]

Hi Richard,

I have a patch on top of your suggested patch from a year ago, that
break the cyclic dependency we're seeing, with this (and a few changes
to the SDK) we can bootstrap clang with submodule local visibility on
darwin. I've attached the patch with a reduced, standalone testcase
that doesn't depend on the SDK. The issues that are not covered by
your patch, that I cover in mine, are related to built-in and textual
headers: they can be found in paths where they don't map to any
modules, triggering other cycles. I fix that by looking further to
find a matching module for the header in question, instead the first
found header in header search.

Can you take a look?

Thanks,


On Thu, Jul 28, 2016 at 3:55 PM, Adrian Prantl via cfe-commits
 wrote:
> +Bruno
>
> On Jul 27, 2016, at 11:58 PM, Nico Weber  wrote:
>
> I played with modules a bit today, and as far as I can tell this is still
> broken. If this proves difficult to fix, should this change be reverted for
> now? It breaks using modules on Darwin.
>
> On Sun, Mar 13, 2016 at 12:53 AM, Adrian Prantl via cfe-commits
>  wrote:
>>
>> > On Mar 11, 2016, at 4:11 PM, Duncan P. N. Exon Smith
>> >  wrote:
>> >
>> > Did anyone file a PR for this?
>> >
>>
>> I filed PR 26928 - Prune the include path for modules
>> https://llvm.org/bugs/show_bug.cgi?id=26928
>> as a starting point.
>>
>> -- adrian
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>



-- 
Bruno Cardoso Lopes
http://www.brunocardoso.cc


0001-Add-NoUndeclaredIncludes-attribute-and-logic.patch
Description: Binary data


0002-Changes-on-top-of-Richard-s-patch.patch
Description: Binary data
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Adrian Prantl via cfe-commits]

+Bruno
> On Jul 27, 2016, at 11:58 PM, Nico Weber  wrote:
> 
> I played with modules a bit today, and as far as I can tell this is still 
> broken. If this proves difficult to fix, should this change be reverted for 
> now? It breaks using modules on Darwin.
> 
> On Sun, Mar 13, 2016 at 12:53 AM, Adrian Prantl via cfe-commits 
> > wrote:
> > On Mar 11, 2016, at 4:11 PM, Duncan P. N. Exon Smith  > > wrote:
> >
> > Did anyone file a PR for this?
> >
> 
> I filed PR 26928 - Prune the include path for modules
> https://llvm.org/bugs/show_bug.cgi?id=26928 
> 
> as a starting point.
> 
> -- adrian
> 
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org 
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits 
> 
> 

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Vassil Vassilev via cfe-commits]

On 17/10/15 01:27, Richard Smith via cfe-commits wrote:
On Thu, Oct 15, 2015 at 11:14 AM, Adrian Prantl > wrote:




On Oct 14, 2015, at 5:07 PM, Richard Smith > wrote:

Ack, there are non-modular headers in the Darwin module. =( I
seem to recall that they're not version-locked to your compiler,
so we've got to support them as-is?

If we can't turn on local submodule visibility, then we need a
module map for libc++ that covers all of its headers. I'll look
into pruning the include path when building a module from an
implicitly-loaded module map.


The attached patch implements this in the most hacky way; with it
I can successfully compile the first few hundred files of LLVM.


Slightly less hacky approach attached, does this also unstick you?

I got bitten by the same issue with ToT clang and xcode 7.3 update.

Did this set of patches land in trunk? Would it make sense the 
properties of NoUndeclaredIncludes to be added to [system] instead?



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Adrian Prantl via cfe-commits]

> On Mar 11, 2016, at 4:11 PM, Duncan P. N. Exon Smith  
> wrote:
> 
> Did anyone file a PR for this?
> 

I filed PR 26928 - Prune the include path for modules 
https://llvm.org/bugs/show_bug.cgi?id=26928
as a starting point.

-- adrian

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Duncan P. N. Exon Smith via cfe-commits]

Did anyone file a PR for this?

> On 2015-Oct-19, at 15:52, Richard Smith via cfe-commits 
>  wrote:
> 
> Ugh, looks like I missed a submodule for stdio.h :(
> 
> On Oct 19, 2015 11:34 AM, "Adrian Prantl"  wrote:
> While building module 'std' imported from 
> /Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/cassert:20:
> While building module 'Darwin' imported from 
> /Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/ctype.h:39:
> In file included from :95:
> In file included from 
> /Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/util.h:64:
> /Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/stdio.h:102:10: 
> fatal error: 
>   '__config' file not found
> #include <__config>
>  ^
> While building module 'std' imported from 
> /Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/cassert:20:
> In file included from :2:
> /Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/ctype.h:39:15: 
> fatal error: 
>   could not build module 'Darwin'
> #include_next 
>  ~^
> In file included from test.cpp:2:
> /Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/cassert:20:10: 
> fatal error: 
>   could not build module 'std'
> #include <__config>
>  ^
> 3 errors generated.
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Adrian Prantl via cfe-commits]

> On Oct 16, 2015, at 5:47 PM, Richard Smith  wrote:
> 
> Great, looks like progress. Next you need a correct module map for libc++ 
> that actually covers all of its headers :) Try the attached one. 
> 
Sorry for the delay.
With the updated module map I get

/Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/module.modulemap:64:14:
 error: 
  header 'locale.h' not found
  header "locale.h"
 ^
/Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/cassert:20:10: 
note: 
  submodule of top-level module 'std' implicitly imported here
#include <__config>
 ^
and after commenting out the locale module I get the rather puzzling (shouldn’t 
this have been avoided by the clang changes?):

While building module 'std' imported from 
/Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/cassert:20:
In file included from :2:
In file included from 
/Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/complex.h:29:
In file included from 
/Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/ccomplex:21:
In file included from 
/Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/complex:244:
/Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/type_traits:219:1:
 error: 
  templates must have C++ linkage
template 
^~~~
/Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/type_traits:222:1:
 error: 
  templates must have C++ linkage
template 
^~~~
/Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/type_traits:225:1:
 error: 
  templates must have C++ linkage
template 
^~

—adrian___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Adrian Prantl via cfe-commits]

While building module 'std' imported from 
/Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/cassert:20:
While building module 'Darwin' imported from 
/Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/ctype.h:39:
In file included from :95:
In file included from 
/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/util.h:64:
/Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/stdio.h:102:10: 
fatal error: 
  '__config' file not found
#include <__config>
 ^
While building module 'std' imported from 
/Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/cassert:20:
In file included from :2:
/Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/ctype.h:39:15: 
fatal error: 
  could not build module 'Darwin'
#include_next 
 ~^
In file included from test.cpp:2:
/Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/cassert:20:10: 
fatal error: 
  could not build module 'std'
#include <__config>
 ^
3 errors generated.___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Richard Smith via cfe-commits]

On Mon, Oct 19, 2015 at 1:28 PM, Adrian Prantl via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
> On Oct 16, 2015, at 5:47 PM, Richard Smith  wrote:
>
> Great, looks like progress. Next you need a correct module map for libc++
> that actually covers all of its headers :) Try the attached one.
>
> Sorry for the delay.
> With the updated module map I get
>
> */Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/module.modulemap:64:14:
> **error: *
> *  header 'locale.h' not found*
>   header "locale.h"
> * ^*
> */Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/cassert:20:10:
> note: *
>   submodule of top-level module 'std' implicitly imported here
> #include <__config>
> * ^*
> and after commenting out the locale module I get the rather puzzling
> (shouldn’t this have been avoided by the clang changes?):
>

Ah right, complex.h should not really be treated as an [extern_c] module.
It doesn't make any sense in that context (... or in general ...). Try the
attached libc++ module map instead (sorry, untested on my end).


> While building module 'std' imported from
> /Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/cassert:20:
> In file included from :2:
> In file included from
> /Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/complex.h:29:
> In file included from
> /Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/ccomplex:21:
> In file included from
> /Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/complex:244:
> */Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/type_traits:219:1:
> **error: *
> *  templates must have C++ linkage*
> template 
> *^~~~*
> */Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/type_traits:222:1:
> **error: *
> *  templates must have C++ linkage*
> template 
> *^~~~*
> */Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/type_traits:225:1:
> **error: *
> *  templates must have C++ linkage*
> template 
> *^~*
>
> —adrian
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>


module.modulemap
Description: Binary data
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Richard Smith via cfe-commits]

Ugh, looks like I missed a submodule for stdio.h :(
On Oct 19, 2015 11:34 AM, "Adrian Prantl"  wrote:

> While building module 'std' imported from
> /Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/cassert:20:
> While building module 'Darwin' imported from
> /Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/ctype.h:39:
> In file included from :95:
> In file included from
> /Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/util.h:64:
> */Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/stdio.h:102:10:
> **fatal error: *
> *  '__config' file not found*
> #include <__config>
> * ^*
> While building module 'std' imported from
> /Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/cassert:20:
> In file included from :2:
> */Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/ctype.h:39:15:
> **fatal error: *
> *  could not build module 'Darwin'*
> #include_next 
> * ~^*
> In file included from test.cpp:2:
> */Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/cassert:20:10:
> **fatal error: *
> *  could not build module 'std'*
> #include <__config>
> * ^*
> 3 errors generated.
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Adrian Prantl via cfe-commits]

> On Oct 16, 2015, at 3:27 PM, Richard Smith  wrote:
> 
> On Thu, Oct 15, 2015 at 11:14 AM, Adrian Prantl  > wrote:
> 
>> On Oct 14, 2015, at 5:07 PM, Richard Smith > > wrote:
>> 
>> Ack, there are non-modular headers in the Darwin module. =( I seem to recall 
>> that they're not version-locked to your compiler, so we've got to support 
>> them as-is?
>> 
>> If we can't turn on local submodule visibility, then we need a module map 
>> for libc++ that covers all of its headers. I'll look into pruning the 
>> include path when building a module from an implicitly-loaded module map.
> 
> The attached patch implements this in the most hacky way; with it I can 
> successfully compile the first few hundred files of LLVM.
> 
> Slightly less hacky approach attached, does this also unstick you? 
> 

Unfortunately, no. After looking at it in the debugger, I believe the problem 
is that HeaderSearch looks at RequestingModule->NoUndeclaredIncludes, but the 
RequestingModule is a nullptr (while looking for cdefs.h included via assert.h, 
for example).

— adrian

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Nico Weber via cfe-commits]

On Wed, Oct 14, 2015 at 5:28 PM, Adrian Prantl via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
> On Oct 14, 2015, at 5:07 PM, Richard Smith  wrote:
>
> On Wed, Oct 14, 2015 at 3:58 PM, Adrian Prantl via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> On Oct 14, 2015, at 3:32 PM, Richard Smith  wrote:
>>
>> On Wed, Oct 14, 2015 at 2:03 PM, Adrian Prantl via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> On Oct 14, 2015, at 11:37 AM, Adrian Prantl via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
>>> On Oct 13, 2015, at 7:43 PM, Richard Smith 
>>> wrote:
>>>
>>> On Tue, Oct 13, 2015 at 6:54 PM, Sean Silva 
>>> wrote:
>>>
 On Tue, Oct 13, 2015 at 6:14 PM, Richard Smith 
 wrote:

> On Tue, Oct 13, 2015 at 5:31 PM, Sean Silva 
> wrote:
>
>> On Tue, Oct 13, 2015 at 3:17 PM, Richard Smith via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> On Tue, Oct 13, 2015 at 2:10 PM, Adrian Prantl via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 Hi Richard,

 this commit appears to break the module self-host on Darwin.

 When compiling the following program generated by clang’s own cmake
 script:

 > #undef NDEBUG
 > #include 
 > #define NDEBUG
 > #include 
 > int main() { assert(this code is not compiled); }

 with clang++ -std=c++11 -fmodules -fcxx-modules test.cpp

>>>
>>> (You don't need -fcxx-modules here.)
>>>
>>>
 I get

 > While building module 'std' imported from
 /Users/buildslave/adrian/
 llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20
 :
 > While building module 'Darwin' imported from
 /Users/buildslave/adrian/
 llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39
 :
 > In file included from :98:
 > In file included from
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/wchar.h:92:
 > In file included from
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/_wctype.h:57:
>>>
>>> > /Users/buildslave/adrian/
 llvm.org/_build.ninja.release/bin/../include/c++/v1/ctype.h:33:10
 :
 fatal error: cyclic dependency in module 'std': std -> Darwin -> std
 > #include <__config>
 >  ^
 > While building module 'std' imported from
 /Users/buildslave/adrian/
 llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20
 :
 > In file included from :1:
 > In file included from /Users/buildslave/adrian/
 llvm.org/_build.ninja.release/bin/../include/c++/v1/algorithm:624
 
 :
 > In file included from /Users/buildslave/adrian/
 llvm.org/_build.ninja.release/bin/../include/c++/v1/initializer_list:47
 
 :
 > /Users/buildslave/adrian/
 llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:10
 :
 fatal error: could not build module 'Darwin'
 > #include 
 >  ^
 > In file included from test.cpp:2:
 > /Users/buildslave/adrian/
 llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:10
 :
 fatal error: could not build module 'std'
 > #include <__config>
 >  ^
 > 3 errors generated.

 Let me know how I can help in diagnosing what’s going on here.

>>>
>>> OK, I see what's wrong. Is this working any better for you in
>>> r250236?
>>>
>>
>> We're still seeing:
>>
>> While building module 'Darwin' imported from /usr/include/assert.h:42:
>> While building module 'std' imported from
>> /path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:
>>
>
> Argh, this is including , which is in the std module. Can
> you try removing the header "type_traits" line from the libc++ module map
> and see if that helps?
>

 I've run into this issue in the past, and I don't think that will fix
 

Re: [libcxx] r249738 - Split out of .

[Adrian Prantl via cfe-commits]

> On Oct 16, 2015, at 5:13 PM, Richard Smith  wrote:
> 
> On Fri, Oct 16, 2015 at 4:48 PM, Adrian Prantl via cfe-commits 
> > wrote:
>> On Oct 16, 2015, at 3:27 PM, Richard Smith > > wrote:
>> 
>> On Thu, Oct 15, 2015 at 11:14 AM, Adrian Prantl > > wrote:
>> 
>>> On Oct 14, 2015, at 5:07 PM, Richard Smith >> > wrote:
>>> 
>>> Ack, there are non-modular headers in the Darwin module. =( I seem to 
>>> recall that they're not version-locked to your compiler, so we've got to 
>>> support them as-is?
>>> 
>>> If we can't turn on local submodule visibility, then we need a module map 
>>> for libc++ that covers all of its headers. I'll look into pruning the 
>>> include path when building a module from an implicitly-loaded module map.
>> 
>> The attached patch implements this in the most hacky way; with it I can 
>> successfully compile the first few hundred files of LLVM.
>> 
>> Slightly less hacky approach attached, does this also unstick you? 
>> 
> 
> Unfortunately, no. After looking at it in the debugger, I believe the problem 
> is that HeaderSearch looks at RequestingModule->NoUndeclaredIncludes, but the 
> RequestingModule is a nullptr (while looking for cdefs.h included via 
> assert.h, for example).
> 
> I see; can you try changing the call to getModuleForLocation at the start of 
> Preprocessor::LookupFile to call getModuleContainingLocation instead? (That 
> change will break decl/use checking, but that's not hard to fix.)

This seems to break other things, but I do get a different result:

In file included from :71:
/Volumes/Data/llvm/_build.ninja.release/bin/../lib/clang/3.8.0/include/stddef.h:118:10:
 fatal error: 
  '__stddef_max_align_t.h' file not found
#include "__stddef_max_align_t.h"
 ^
In file included from test.cpp:2:
In file included from 
/Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/cassert:21:
/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/assert.h:42:10:
 fatal error: 
  could not build module 'Darwin'
#include 
 ^
2 errors generated.

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Adrian Prantl via cfe-commits]

> On Oct 16, 2015, at 5:28 PM, Richard Smith  wrote:
> 
> 

Getting there :-)

In file included from :86:
In file included from 
/Volumes/Data/llvm/_build.ninja.release/bin/../lib/clang/3.8.0/include/tgmath.h:29:
/Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/math.h:309:10: 
fatal error: 
  'type_traits' file not found
#include 
 ^
In file included from test.cpp:2:
In file included from 
/Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/cassert:21:
/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/assert.h:42:10:
 fatal error: 
  could not build module 'Darwin'
#include 
 ^
2 errors generated.

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Adrian Prantl via cfe-commits]

> On Oct 16, 2015, at 5:30 PM, Adrian Prantl via cfe-commits 
>  wrote:
> 
> 
>> On Oct 16, 2015, at 5:28 PM, Richard Smith > > wrote:
>> 
>> 
> 
> Getting there :-)
> 
While building module 'Darwin' imported from 
/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/assert.h:42:
> In file included from :86:
> In file included from 
> /Volumes/Data/llvm/_build.ninja.release/bin/../lib/clang/3.8.0/include/tgmath.h:29:
> /Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/math.h:309:10: 
> fatal error: 
>   'type_traits' file not found
> #include 
>  ^
> In file included from test.cpp:2:
> In file included from 
> /Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/cassert:21:
> /Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/assert.h:42:10:
>  fatal error: 
>   could not build module 'Darwin'
> #include 
>  ^
> 2 errors generated.
> 
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Richard Smith via cfe-commits]

On Fri, Oct 16, 2015 at 4:48 PM, Adrian Prantl via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Oct 16, 2015, at 3:27 PM, Richard Smith  wrote:
>
> On Thu, Oct 15, 2015 at 11:14 AM, Adrian Prantl  wrote:
>
>>
>> On Oct 14, 2015, at 5:07 PM, Richard Smith  wrote:
>>
>> Ack, there are non-modular headers in the Darwin module. =( I seem to
>> recall that they're not version-locked to your compiler, so we've got to
>> support them as-is?
>>
>> If we can't turn on local submodule visibility, then we need a module map
>> for libc++ that covers all of its headers. I'll look into pruning the
>> include path when building a module from an implicitly-loaded module map.
>>
>>
>> The attached patch implements this in the most hacky way; with it I can
>> successfully compile the first few hundred files of LLVM.
>>
>
> Slightly less hacky approach attached, does this also unstick you?
> 
>
>
> Unfortunately, no. After looking at it in the debugger, I believe the
> problem is that HeaderSearch looks
> at RequestingModule->NoUndeclaredIncludes, but the RequestingModule is a
> nullptr (while looking for cdefs.h included via assert.h, for example).
>

I see; can you try changing the call to getModuleForLocation at the start
of Preprocessor::LookupFile to call getModuleContainingLocation instead?
(That change will break decl/use checking, but that's not hard to fix.)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Richard Smith via cfe-commits]

On Fri, Oct 16, 2015 at 5:17 PM, Adrian Prantl via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Oct 16, 2015, at 5:13 PM, Richard Smith  wrote:
>
> On Fri, Oct 16, 2015 at 4:48 PM, Adrian Prantl via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> On Oct 16, 2015, at 3:27 PM, Richard Smith  wrote:
>>
>> On Thu, Oct 15, 2015 at 11:14 AM, Adrian Prantl 
>> wrote:
>>
>>>
>>> On Oct 14, 2015, at 5:07 PM, Richard Smith 
>>> wrote:
>>>
>>> Ack, there are non-modular headers in the Darwin module. =( I seem to
>>> recall that they're not version-locked to your compiler, so we've got to
>>> support them as-is?
>>>
>>> If we can't turn on local submodule visibility, then we need a module
>>> map for libc++ that covers all of its headers. I'll look into pruning the
>>> include path when building a module from an implicitly-loaded module map.
>>>
>>>
>>> The attached patch implements this in the most hacky way; with it I can
>>> successfully compile the first few hundred files of LLVM.
>>>
>>
>> Slightly less hacky approach attached, does this also unstick you?
>> 
>>
>>
>> Unfortunately, no. After looking at it in the debugger, I believe the
>> problem is that HeaderSearch looks
>> at RequestingModule->NoUndeclaredIncludes, but the RequestingModule is a
>> nullptr (while looking for cdefs.h included via assert.h, for example).
>>
>
> I see; can you try changing the call to getModuleForLocation at the start
> of Preprocessor::LookupFile to call getModuleContainingLocation instead?
> (That change will break decl/use checking, but that's not hard to fix.)
>
>
> This seems to break other things, but I do get a different result:
>
> In file included from :71:
> */Volumes/Data/llvm/_build.ninja.release/bin/../lib/clang/3.8.0/include/stddef.h:118:10:
> **fatal error: *
> *  '__stddef_max_align_t.h' file not found*
> #include "__stddef_max_align_t.h"
> * ^*
> In file included from test.cpp:2:
> In file included from
> /Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/cassert:21:
> */Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/assert.h:42:10:
> **fatal error: *
> *  could not build module 'Darwin'*
> #include 
> * ^*
> 2 errors generated.
>

Ha, yes, it would break that :) We need an implicit dependency on clang's
_Builtin_stddef_max_align_t module to make that work. That's a pre-existing
bug; try adding the attached patch.
Index: lib/Basic/Module.cpp
===
--- lib/Basic/Module.cpp(revision 250139)
+++ lib/Basic/Module.cpp(working copy)
@@ -32,7 +32,8 @@
   IsFramework(IsFramework), IsExplicit(IsExplicit), IsSystem(false),
   IsExternC(false), IsInferred(false), InferSubmodules(false),
   InferExplicitSubmodules(false), InferExportWildcard(false),
-  ConfigMacrosExhaustive(false), NameVisibility(Hidden) {
+  ConfigMacrosExhaustive(false), NoUndeclaredIncludes(false),
+  NameVisibility(Hidden) {
   if (Parent) {
 if (!Parent->isAvailable())
   IsAvailable = false;
@@ -40,6 +41,8 @@
   IsSystem = true;
 if (Parent->IsExternC)
   IsExternC = true;
+if (Parent->NoUndeclaredIncludes)
+  NoUndeclaredIncludes = true;
 IsMissingRequirement = Parent->IsMissingRequirement;
 
 Parent->SubModuleIndex[Name] = Parent->SubModules.size();
@@ -178,6 +181,11 @@
   for (auto *Use : Top->DirectUses)
 if (Requested->isSubModuleOf(Use))
   return true;
+
+  // Anyone is allowed to use our builtin stddef.h and its accompanying module.
+  if (!Requested->Parent && Requested->Name == "_Builtin_stddef_max_align_t")
+return true;
+
   return false;
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Richard Smith via cfe-commits]

On Thu, Oct 15, 2015 at 11:14 AM, Adrian Prantl  wrote:

>
> On Oct 14, 2015, at 5:07 PM, Richard Smith  wrote:
>
> Ack, there are non-modular headers in the Darwin module. =( I seem to
> recall that they're not version-locked to your compiler, so we've got to
> support them as-is?
>
> If we can't turn on local submodule visibility, then we need a module map
> for libc++ that covers all of its headers. I'll look into pruning the
> include path when building a module from an implicitly-loaded module map.
>
>
> The attached patch implements this in the most hacky way; with it I can
> successfully compile the first few hundred files of LLVM.
>

Slightly less hacky approach attached, does this also unstick you?
Index: include/clang/Basic/Module.h
===
--- include/clang/Basic/Module.h(revision 250139)
+++ include/clang/Basic/Module.h(working copy)
@@ -200,6 +200,10 @@
   /// built.
   unsigned ConfigMacrosExhaustive : 1;
 
+  /// \brief Whether files in this module can only include files from used
+  /// modules.
+  unsigned NoUndeclaredIncludes : 1;
+
   /// \brief Describes the visibility of the various names within a
   /// particular module.
   enum NameVisibilityKind {
Index: include/clang/Lex/ModuleMap.h
===
--- include/clang/Lex/ModuleMap.h   (revision 250139)
+++ include/clang/Lex/ModuleMap.h   (working copy)
@@ -157,7 +157,8 @@
 
   /// \brief The set of attributes that can be attached to a module.
   struct Attributes {
-Attributes() : IsSystem(), IsExternC(), IsExhaustive() {}
+Attributes()
+: IsSystem(), IsExternC(), IsExhaustive(), NoUndeclaredIncludes() {}
 
 /// \brief Whether this is a system module.
 unsigned IsSystem : 1;
@@ -167,6 +168,10 @@
 
 /// \brief Whether this is an exhaustive set of configuration macros.
 unsigned IsExhaustive : 1;
+
+/// \brief Whether files in this module can only include files from
+/// explicit dependencies of the module.
+unsigned NoUndeclaredIncludes : 1;
   };
 
   /// \brief A directory for which framework modules can be inferred.
Index: lib/Basic/Module.cpp
===
--- lib/Basic/Module.cpp(revision 250139)
+++ lib/Basic/Module.cpp(working copy)
@@ -32,7 +32,8 @@
   IsFramework(IsFramework), IsExplicit(IsExplicit), IsSystem(false),
   IsExternC(false), IsInferred(false), InferSubmodules(false),
   InferExplicitSubmodules(false), InferExportWildcard(false),
-  ConfigMacrosExhaustive(false), NameVisibility(Hidden) {
+  ConfigMacrosExhaustive(false), NoUndeclaredIncludes(false),
+  NameVisibility(Hidden) {
   if (Parent) {
 if (!Parent->isAvailable())
   IsAvailable = false;
@@ -40,6 +41,8 @@
   IsSystem = true;
 if (Parent->IsExternC)
   IsExternC = true;
+if (Parent->NoUndeclaredIncludes)
+  NoUndeclaredIncludes = true;
 IsMissingRequirement = Parent->IsMissingRequirement;
 
 Parent->SubModuleIndex[Name] = Parent->SubModules.size();
Index: lib/Lex/HeaderSearch.cpp
===
--- lib/Lex/HeaderSearch.cpp(revision 250554)
+++ lib/Lex/HeaderSearch.cpp(working copy)
@@ -393,6 +393,12 @@
   return TopFrameworkDir;
 }
 
+static bool needModuleLookup(Module *RequestingModule,
+ bool HasSuggestedModule) {
+  return HasSuggestedModule ||
+ (RequestingModule && RequestingModule->NoUndeclaredIncludes);
+}
+
 /// DoFrameworkLookup - Do a lookup of the specified file in the current
 /// DirectoryLookup, which is a framework directory.
 const FileEntry *DirectoryLookup::DoFrameworkLookup(
@@ -488,7 +494,7 @@
   }
 
   // If we found the header and are allowed to suggest a module, do so now.
-  if (FE && SuggestedModule) {
+  if (FE && needModuleLookup(RequestingModule, SuggestedModule)) {
 // Find the framework in which this header occurs.
 StringRef FrameworkPath = FE->getDir()->getName();
 bool FoundFramework = false;
@@ -1144,13 +1150,31 @@
   return ModMap.findModuleForHeader(File);
 }
 
+static bool suggestModule(HeaderSearch , const FileEntry *File,
+  Module *RequestingModule,
+  ModuleMap::KnownHeader *SuggestedModule) {
+  ModuleMap::KnownHeader Module = HS.findModuleForHeader(File);
+  if (SuggestedModule)
+*SuggestedModule = Module;
+
+  // If this module specifies [no_undeclared_includes], we cannot find any
+  // file that's in a non-dependency module.
+  if (RequestingModule && Module && RequestingModule->NoUndeclaredIncludes) {
+HS.getModuleMap().resolveUses(RequestingModule, /*Complain*/false);
+if (!RequestingModule->directlyUses(Module.getModule()))
+  return false;
+  }
+
+  return true;
+}
+
 bool 

Re: [libcxx] r249738 - Split out of .

[Richard Smith via cfe-commits]

On Fri, Oct 16, 2015 at 5:30 PM, Adrian Prantl via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
> On Oct 16, 2015, at 5:28 PM, Richard Smith  wrote:
>
> 
>
>
> Getting there :-)
>
> In file included from :86:
> In file included from
> /Volumes/Data/llvm/_build.ninja.release/bin/../lib/clang/3.8.0/include/tgmath.h:29:
> */Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/math.h:309:10:
> **fatal error: *
> *  'type_traits' file not found*
> #include 
> * ^*
> In file included from test.cpp:2:
> In file included from
> /Volumes/Data/llvm/_build.ninja.release/bin/../include/c++/v1/cassert:21:
> */Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/assert.h:42:10:
> **fatal error: *
> *  could not build module 'Darwin'*
> #include 
> * ^*
> 2 errors generated.
>

Great, looks like progress. Next you need a correct module map for libc++
that actually covers all of its headers :) Try the attached one.


module.modulemap
Description: Binary data
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Adrian Prantl via cfe-commits]

> On Oct 15, 2015, at 1:42 PM, Richard Smith  wrote:
> 
> On Thu, Oct 15, 2015 at 11:14 AM, Adrian Prantl  > wrote:
> 
>> On Oct 14, 2015, at 5:07 PM, Richard Smith > > wrote:
>> 
>> Ack, there are non-modular headers in the Darwin module. =( I seem to recall 
>> that they're not version-locked to your compiler, so we've got to support 
>> them as-is?
>> 
>> If we can't turn on local submodule visibility, then we need a module map 
>> for libc++ that covers all of its headers. I'll look into pruning the 
>> include path when building a module from an implicitly-loaded module map.
> 
> The attached patch implements this in the most hacky way; with it I can 
> successfully compile the first few hundred files of LLVM.
> 
> Great, it looks like this plan should work then. What failure do you 
> eventually hit? Does it look related to these  changes?

So far I fixed 250446  and 250459 which were both just missing include files. 
I’m puzzled by 250459 though, as there is nothing Darwin-specific about the 
change. I’ll keep iterating and will let you know if there are any 
libc++-related problems.

> 
> I'm working on a more refined version of the approach I described earlier; 
> I'll mail you a patch to test when I have it finished.

That sounds great.

thanks,
adrian___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Richard Smith via cfe-commits]

On Thu, Oct 15, 2015 at 2:57 PM, Adrian Prantl via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Oct 15, 2015, at 2:51 PM, Alex Rosenberg  wrote:
>
> On Oct 15, 2015, at 2:20 PM, Adrian Prantl via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>
> On Oct 15, 2015, at 2:09 PM, Adrian Prantl via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>
> On Oct 15, 2015, at 1:42 PM, Richard Smith  wrote:
>
> On Thu, Oct 15, 2015 at 11:14 AM, Adrian Prantl  wrote:
>
>>
>> On Oct 14, 2015, at 5:07 PM, Richard Smith  wrote:
>>
>> Ack, there are non-modular headers in the Darwin module. =( I seem to
>> recall that they're not version-locked to your compiler, so we've got to
>> support them as-is?
>>
>> If we can't turn on local submodule visibility, then we need a module map
>> for libc++ that covers all of its headers. I'll look into pruning the
>> include path when building a module from an implicitly-loaded module map.
>>
>>
>> The attached patch implements this in the most hacky way; with it I can
>> successfully compile the first few hundred files of LLVM.
>>
>
> Great, it looks like this plan should work then. What failure do you
> eventually hit? Does it look related to these  changes?
>
>
> So far I fixed 250446  and 250459 which were both just missing include
> files. I’m puzzled by 250459 though, as there is nothing Darwin-specific
> about the change. I’ll keep iterating and will let you know if there are
> any libc++-related problems.
>
>
> I'm working on a more refined version of the approach I described earlier;
> I'll mail you a patch to test when I have it finished.
>
>
> That sounds great.
>
> thanks,
> adrian
>
>
> Here’s a weird one:
>
> *../lib/Transforms/Scalar/ScalarReplAggregates.cpp:1031:6: **error: **'SROA'
> is not a class, namespace, or enumeration*
> bool SROA::runOnFunction(Function ) {
> * ^*
> *../lib/Transforms/Scalar/ScalarReplAggregates.cpp:1031:6: **error: 
> **reference
> to 'SROA' is ambiguous*
> *../include/llvm/Transforms/Scalar/SROA.h:54:7: note: *candidate found by
> name lookup is 'llvm::SROA'
> class SROA {
> *  ^*
> *../lib/Transforms/Scalar/ScalarReplAggregates.cpp:63:10: note: *candidate
> found by name lookup is '(anonymous namespace)::SROA'
>   struct SROA : public FunctionPass {
> * ^*
>
> this doesn’t look Darwin-specific at all. Assuming that the Linux module
> build works, why am I seeing this?
>
>
> The Linux bot has the same problem:
> http://lab.llvm.org:8011/builders/clang-x86_64-linux-selfhost-modules/builds/7331/steps/compile.llvm.stage2/logs/stdio
>
>
> Oh :-) That bot does not look very happy:
>
> http://lab.llvm.org:8011/builders/clang-x86_64-linux-selfhost-modules?numbuilds=1000
>

Investigating that is ~third on my todo list at the moment. I suspect this
is a Clang bug; I don't know why we have two different SROA passes, but
ScalarReplAggregates.cpp doesn't make SROA.h visible, so the two names
should not conflict.


> What’s the appropriate solution, renaming the struct ::SROA in the
> anonymous namespace to something else?
>
> — adrian
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Richard Smith via cfe-commits]

On Thu, Oct 15, 2015 at 2:57 PM, Adrian Prantl via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Oct 15, 2015, at 2:51 PM, Alex Rosenberg  wrote:
>
> On Oct 15, 2015, at 2:20 PM, Adrian Prantl via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>
> On Oct 15, 2015, at 2:09 PM, Adrian Prantl via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>
> On Oct 15, 2015, at 1:42 PM, Richard Smith  wrote:
>
> On Thu, Oct 15, 2015 at 11:14 AM, Adrian Prantl  wrote:
>
>>
>> On Oct 14, 2015, at 5:07 PM, Richard Smith  wrote:
>>
>> Ack, there are non-modular headers in the Darwin module. =( I seem to
>> recall that they're not version-locked to your compiler, so we've got to
>> support them as-is?
>>
>> If we can't turn on local submodule visibility, then we need a module map
>> for libc++ that covers all of its headers. I'll look into pruning the
>> include path when building a module from an implicitly-loaded module map.
>>
>>
>> The attached patch implements this in the most hacky way; with it I can
>> successfully compile the first few hundred files of LLVM.
>>
>
> Great, it looks like this plan should work then. What failure do you
> eventually hit? Does it look related to these  changes?
>
>
> So far I fixed 250446  and 250459 which were both just missing include
> files. I’m puzzled by 250459 though, as there is nothing Darwin-specific
> about the change. I’ll keep iterating and will let you know if there are
> any libc++-related problems.
>
>
> I'm working on a more refined version of the approach I described earlier;
> I'll mail you a patch to test when I have it finished.
>
>
> That sounds great.
>
> thanks,
> adrian
>
>
> Here’s a weird one:
>
> *../lib/Transforms/Scalar/ScalarReplAggregates.cpp:1031:6: **error: **'SROA'
> is not a class, namespace, or enumeration*
> bool SROA::runOnFunction(Function ) {
> * ^*
> *../lib/Transforms/Scalar/ScalarReplAggregates.cpp:1031:6: **error: 
> **reference
> to 'SROA' is ambiguous*
> *../include/llvm/Transforms/Scalar/SROA.h:54:7: note: *candidate found by
> name lookup is 'llvm::SROA'
> class SROA {
> *  ^*
> *../lib/Transforms/Scalar/ScalarReplAggregates.cpp:63:10: note: *candidate
> found by name lookup is '(anonymous namespace)::SROA'
>   struct SROA : public FunctionPass {
> * ^*
>
> this doesn’t look Darwin-specific at all. Assuming that the Linux module
> build works, why am I seeing this?
>
>
> The Linux bot has the same problem:
> http://lab.llvm.org:8011/builders/clang-x86_64-linux-selfhost-modules/builds/7331/steps/compile.llvm.stage2/logs/stdio
>
>
> Oh :-) That bot does not look very happy:
>
> http://lab.llvm.org:8011/builders/clang-x86_64-linux-selfhost-modules?numbuilds=1000
>
> What’s the appropriate solution, renaming the struct ::SROA in the
> anonymous namespace to something else?
>

Oh, and please don't do that: the point of the modules selfhost bot is to
find bugs in Clang's modules implementation. We shouldn't make changes to
the LLVM code to make the build pass unless the problem is known to be a
bug in the code being compiled rather than a bug in the compiler.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Richard Smith via cfe-commits]

On Thu, Oct 15, 2015 at 11:14 AM, Adrian Prantl  wrote:

>
> On Oct 14, 2015, at 5:07 PM, Richard Smith  wrote:
>
> Ack, there are non-modular headers in the Darwin module. =( I seem to
> recall that they're not version-locked to your compiler, so we've got to
> support them as-is?
>
> If we can't turn on local submodule visibility, then we need a module map
> for libc++ that covers all of its headers. I'll look into pruning the
> include path when building a module from an implicitly-loaded module map.
>
>
> The attached patch implements this in the most hacky way; with it I can
> successfully compile the first few hundred files of LLVM.
>

Great, it looks like this plan should work then. What failure do you
eventually hit? Does it look related to these  changes?

I'm working on a more refined version of the approach I described earlier;
I'll mail you a patch to test when I have it finished.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Adrian Prantl via cfe-commits]

> On Oct 15, 2015, at 2:09 PM, Adrian Prantl via cfe-commits 
>  wrote:
> 
>> 
>> On Oct 15, 2015, at 1:42 PM, Richard Smith > > wrote:
>> 
>> On Thu, Oct 15, 2015 at 11:14 AM, Adrian Prantl > > wrote:
>> 
>>> On Oct 14, 2015, at 5:07 PM, Richard Smith >> > wrote:
>>> 
>>> Ack, there are non-modular headers in the Darwin module. =( I seem to 
>>> recall that they're not version-locked to your compiler, so we've got to 
>>> support them as-is?
>>> 
>>> If we can't turn on local submodule visibility, then we need a module map 
>>> for libc++ that covers all of its headers. I'll look into pruning the 
>>> include path when building a module from an implicitly-loaded module map.
>> 
>> The attached patch implements this in the most hacky way; with it I can 
>> successfully compile the first few hundred files of LLVM.
>> 
>> Great, it looks like this plan should work then. What failure do you 
>> eventually hit? Does it look related to these  changes?
> 
> So far I fixed 250446  and 250459 which were both just missing include files. 
> I’m puzzled by 250459 though, as there is nothing Darwin-specific about the 
> change. I’ll keep iterating and will let you know if there are any 
> libc++-related problems.
> 
>> 
>> I'm working on a more refined version of the approach I described earlier; 
>> I'll mail you a patch to test when I have it finished.
> 
> That sounds great.
> 
> thanks,
> adrian

Here’s a weird one:

../lib/Transforms/Scalar/ScalarReplAggregates.cpp:1031:6: error: 'SROA' is not 
a class, namespace, or enumeration
bool SROA::runOnFunction(Function ) {
 ^
../lib/Transforms/Scalar/ScalarReplAggregates.cpp:1031:6: error: reference to 
'SROA' is ambiguous
../include/llvm/Transforms/Scalar/SROA.h:54:7: note: candidate found by name 
lookup is 'llvm::SROA'
class SROA {
  ^
../lib/Transforms/Scalar/ScalarReplAggregates.cpp:63:10: note: candidate found 
by name lookup is '(anonymous namespace)::SROA'
  struct SROA : public FunctionPass {
 ^

this doesn’t look Darwin-specific at all. Assuming that the Linux module build 
works, why am I seeing this?

— adrian___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Alex Rosenberg via cfe-commits]

On Oct 15, 2015, at 2:20 PM, Adrian Prantl via cfe-commits 
 wrote:

>> 
>> On Oct 15, 2015, at 2:09 PM, Adrian Prantl via cfe-commits 
>>  wrote:
>> 
>>> 
>>> On Oct 15, 2015, at 1:42 PM, Richard Smith  wrote:
>>> 
>>> On Thu, Oct 15, 2015 at 11:14 AM, Adrian Prantl  wrote:
>>> 
 On Oct 14, 2015, at 5:07 PM, Richard Smith  wrote:
 
 Ack, there are non-modular headers in the Darwin module. =( I seem to 
 recall that they're not version-locked to your compiler, so we've got to 
 support them as-is?
 
 If we can't turn on local submodule visibility, then we need a module map 
 for libc++ that covers all of its headers. I'll look into pruning the 
 include path when building a module from an implicitly-loaded module map.
>>> 
>>> The attached patch implements this in the most hacky way; with it I can 
>>> successfully compile the first few hundred files of LLVM.
>>> 
>>> Great, it looks like this plan should work then. What failure do you 
>>> eventually hit? Does it look related to these  changes?
>> 
>> So far I fixed 250446  and 250459 which were both just missing include 
>> files. I’m puzzled by 250459 though, as there is nothing Darwin-specific 
>> about the change. I’ll keep iterating and will let you know if there are any 
>> libc++-related problems.
>> 
>>> 
>>> I'm working on a more refined version of the approach I described earlier; 
>>> I'll mail you a patch to test when I have it finished.
>> 
>> That sounds great.
>> 
>> thanks,
>> adrian
> 
> Here’s a weird one:
> 
> ../lib/Transforms/Scalar/ScalarReplAggregates.cpp:1031:6: error: 'SROA' is 
> not a class, namespace, or enumeration
> bool SROA::runOnFunction(Function ) {
>  ^
> ../lib/Transforms/Scalar/ScalarReplAggregates.cpp:1031:6: error: reference to 
> 'SROA' is ambiguous
> ../include/llvm/Transforms/Scalar/SROA.h:54:7: note: candidate found by name 
> lookup is 'llvm::SROA'
> class SROA {
>   ^
> ../lib/Transforms/Scalar/ScalarReplAggregates.cpp:63:10: note: candidate 
> found by name lookup is '(anonymous namespace)::SROA'
>   struct SROA : public FunctionPass {
>  ^
> 
> this doesn’t look Darwin-specific at all. Assuming that the Linux module 
> build works, why am I seeing this?

The Linux bot has the same problem: 
http://lab.llvm.org:8011/builders/clang-x86_64-linux-selfhost-modules/builds/7331/steps/compile.llvm.stage2/logs/stdio

++
| Alexander M. Rosenberg |
| Nobody cares what I say, so no disclaimer appears here.|

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Adrian Prantl via cfe-commits]

> On Oct 15, 2015, at 2:51 PM, Alex Rosenberg  wrote:
> 
> On Oct 15, 2015, at 2:20 PM, Adrian Prantl via cfe-commits 
> > wrote:
> 
>>> 
>>> On Oct 15, 2015, at 2:09 PM, Adrian Prantl via cfe-commits 
>>> > wrote:
>>> 
 
 On Oct 15, 2015, at 1:42 PM, Richard Smith > wrote:
 
 On Thu, Oct 15, 2015 at 11:14 AM, Adrian Prantl > wrote:
 
> On Oct 14, 2015, at 5:07 PM, Richard Smith  > wrote:
> 
> Ack, there are non-modular headers in the Darwin module. =( I seem to 
> recall that they're not version-locked to your compiler, so we've got to 
> support them as-is?
> 
> If we can't turn on local submodule visibility, then we need a module map 
> for libc++ that covers all of its headers. I'll look into pruning the 
> include path when building a module from an implicitly-loaded module map.
 
 The attached patch implements this in the most hacky way; with it I can 
 successfully compile the first few hundred files of LLVM.
 
 Great, it looks like this plan should work then. What failure do you 
 eventually hit? Does it look related to these  changes?
>>> 
>>> So far I fixed 250446  and 250459 which were both just missing include 
>>> files. I’m puzzled by 250459 though, as there is nothing Darwin-specific 
>>> about the change. I’ll keep iterating and will let you know if there are 
>>> any libc++-related problems.
>>> 
 
 I'm working on a more refined version of the approach I described earlier; 
 I'll mail you a patch to test when I have it finished.
>>> 
>>> That sounds great.
>>> 
>>> thanks,
>>> adrian
>> 
>> Here’s a weird one:
>> 
>> ../lib/Transforms/Scalar/ScalarReplAggregates.cpp:1031:6: error: 'SROA' is 
>> not a class, namespace, or enumeration
>> bool SROA::runOnFunction(Function ) {
>>  ^
>> ../lib/Transforms/Scalar/ScalarReplAggregates.cpp:1031:6: error: reference 
>> to 'SROA' is ambiguous
>> ../include/llvm/Transforms/Scalar/SROA.h:54:7: note: candidate found by name 
>> lookup is 'llvm::SROA'
>> class SROA {
>>   ^
>> ../lib/Transforms/Scalar/ScalarReplAggregates.cpp:63:10: note: candidate 
>> found by name lookup is '(anonymous namespace)::SROA'
>>   struct SROA : public FunctionPass {
>>  ^
>> 
>> this doesn’t look Darwin-specific at all. Assuming that the Linux module 
>> build works, why am I seeing this?
> 
> The Linux bot has the same problem: 
> http://lab.llvm.org:8011/builders/clang-x86_64-linux-selfhost-modules/builds/7331/steps/compile.llvm.stage2/logs/stdio
>  
> 
Oh :-) That bot does not look very happy:
http://lab.llvm.org:8011/builders/clang-x86_64-linux-selfhost-modules?numbuilds=1000

What’s the appropriate solution, renaming the struct ::SROA in the anonymous 
namespace to something else?

— adrian___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Adrian Prantl via cfe-commits]

On Oct 14, 2015, at 5:07 PM, Richard Smith  wrote:Ack, there are non-modular headers in the Darwin module. =( I seem to recall that they're not version-locked to your compiler, so we've got to support them as-is?If we can't turn on local submodule visibility, then we need a module map for libc++ that covers all of its headers. I'll look into pruning the include path when building a module from an implicitly-loaded module map.The attached patch implements this in the most hacky way; with it I can successfully compile the first few hundred files of LLVM.— adrian

ignorelibc++.diff
Description: Binary data
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Adrian Prantl via cfe-commits]

To make it easier to find and investigate issues like this, I set up an 
experimental bot on the Green Dragon Jenkins installation on lab.llvm.org that 
builds a stage2 on Darwin with LLVM_ENABLE_MODULES:

  http://lab.llvm.org:8080/green/job/clang-stage2-cmake-modulesRDA/

I’ve configured it to dump the output of the CMake error log to facilitate 
diagnosis:

  
http://lab.llvm.org:8080/green/job/clang-stage2-cmake-modulesRDA_build/5/consoleFull#2020635013e9a0fee5-ebcc-4238-a641-c5aa112c323e

-- adrian
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Adrian Prantl via cfe-commits]

> On Oct 13, 2015, at 7:43 PM, Richard Smith  wrote:
> 
> On Tue, Oct 13, 2015 at 6:54 PM, Sean Silva  > wrote:
> On Tue, Oct 13, 2015 at 6:14 PM, Richard Smith  > wrote:
> On Tue, Oct 13, 2015 at 5:31 PM, Sean Silva  > wrote:
> On Tue, Oct 13, 2015 at 3:17 PM, Richard Smith via cfe-commits 
> > wrote:
> On Tue, Oct 13, 2015 at 2:10 PM, Adrian Prantl via cfe-commits 
> > wrote:
> Hi Richard,
> 
> this commit appears to break the module self-host on Darwin.
> 
> When compiling the following program generated by clang’s own cmake script:
> 
> > #undef NDEBUG
> > #include 
> > #define NDEBUG
> > #include 
> > int main() { assert(this code is not compiled); }
> 
> with clang++ -std=c++11 -fmodules -fcxx-modules test.cpp
> 
> (You don't need -fcxx-modules here.)
>  
> I get
> 
> > While building module 'std' imported from 
> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20
> >  :
> > While building module 'Darwin' imported from 
> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39
> >  :
> > In file included from :98:
> > In file included from 
> > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/wchar.h:92:
> > In file included from 
> > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/_wctype.h:57:
> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/ctype.h:33:10
> >  : fatal 
> > error: cyclic dependency in module 'std': std -> Darwin -> std
> > #include <__config>
> >  ^
> > While building module 'std' imported from 
> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20
> >  :
> > In file included from :1:
> > In file included from 
> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/algorithm:624
> >  :
> > In file included from 
> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/initializer_list:47
> >  :
> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:10
> >  : fatal 
> > error: could not build module 'Darwin'
> > #include 
> >  ^
> > In file included from test.cpp:2:
> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:10
> >  : fatal 
> > error: could not build module 'std'
> > #include <__config>
> >  ^
> > 3 errors generated.
> 
> Let me know how I can help in diagnosing what’s going on here.
> 
> OK, I see what's wrong. Is this working any better for you in r250236?
> 
> We're still seeing:
> 
> While building module 'Darwin' imported from /usr/include/assert.h:42:
> While building module 'std' imported from 
> /path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:
> 
> Argh, this is including , which is in the std module. Can you 
> try removing the header "type_traits" line from the libc++ module map and see 
> if that helps?
> 
> I've run into this issue in the past, and I don't think that will fix it (see 
> below). Just to be sure, here is the output with type_traits removed from the 
> module map::
> 
> While building module 'Darwin' imported from /usr/include/assert.h:42:
> While building module 'std' imported from 
> /path/to/build_cmake/stage1/bin/../include/c++/v1/type_traits:211:
> 
> That's an include of . We'd need to apply this workaround to that 
> header too (but I think the buck stops there).

After commenting out the cstddef module as well, the test case compiles again. 
Should I commit that and the type_traits change to libcxx, or are you working 
on a better fix?

-- adrian

> 
> In file included from :1:
> In file included from 
> /path/to/build_cmake/stage1/bin/../include/c++/v1/algorithm:624:
> In file included from 
> /path/to/build_cmake/stage1/bin/../include/c++/v1/initializer_list:47:
> In file included from 
> /path/to/build_cmake/stage1/bin/../include/c++/v1/cstddef:43:
> /path/to/build_cmake/stage1/bin/../include/c++/v1/stddef.h:46:15: fatal 
> error: cyclic dependency in module 'Darwin': Darwin -> 

Re: [libcxx] r249738 - Split out of .

[Adrian Prantl via cfe-commits]

> On Oct 14, 2015, at 3:32 PM, Richard Smith  wrote:
> 
> On Wed, Oct 14, 2015 at 2:03 PM, Adrian Prantl via cfe-commits 
> > wrote:
>> On Oct 14, 2015, at 11:37 AM, Adrian Prantl via cfe-commits 
>> > wrote:
>>> On Oct 13, 2015, at 7:43 PM, Richard Smith >> > wrote:
>>> 
>>> On Tue, Oct 13, 2015 at 6:54 PM, Sean Silva >> > wrote:
>>> On Tue, Oct 13, 2015 at 6:14 PM, Richard Smith >> > wrote:
>>> On Tue, Oct 13, 2015 at 5:31 PM, Sean Silva >> > wrote:
>>> On Tue, Oct 13, 2015 at 3:17 PM, Richard Smith via cfe-commits 
>>> > wrote:
>>> On Tue, Oct 13, 2015 at 2:10 PM, Adrian Prantl via cfe-commits 
>>> > wrote:
>>> Hi Richard,
>>> 
>>> this commit appears to break the module self-host on Darwin.
>>> 
>>> When compiling the following program generated by clang’s own cmake script:
>>> 
>>> > #undef NDEBUG
>>> > #include 
>>> > #define NDEBUG
>>> > #include 
>>> > int main() { assert(this code is not compiled); }
>>> 
>>> with clang++ -std=c++11 -fmodules -fcxx-modules test.cpp
>>> 
>>> (You don't need -fcxx-modules here.)
>>>  
>>> I get
>>> 
>>> > While building module 'std' imported from 
>>> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20
>>> >  :
>>> > While building module 'Darwin' imported from 
>>> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39
>>> >  :
>>> > In file included from :98:
>>> > In file included from 
>>> > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/wchar.h:92:
>>> > In file included from 
>>> > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/_wctype.h:57:
>>> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/ctype.h:33:10
>>> >  : 
>>> > fatal error: cyclic dependency in module 'std': std -> Darwin -> std
>>> > #include <__config>
>>> >  ^
>>> > While building module 'std' imported from 
>>> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20
>>> >  :
>>> > In file included from :1:
>>> > In file included from 
>>> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/algorithm:624
>>> >  :
>>> > In file included from 
>>> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/initializer_list:47
>>> >  
>>> > :
>>> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:10
>>> >  : 
>>> > fatal error: could not build module 'Darwin'
>>> > #include 
>>> >  ^
>>> > In file included from test.cpp:2:
>>> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:10
>>> >  : 
>>> > fatal error: could not build module 'std'
>>> > #include <__config>
>>> >  ^
>>> > 3 errors generated.
>>> 
>>> Let me know how I can help in diagnosing what’s going on here.
>>> 
>>> OK, I see what's wrong. Is this working any better for you in r250236?
>>> 
>>> We're still seeing:
>>> 
>>> While building module 'Darwin' imported from /usr/include/assert.h:42:
>>> While building module 'std' imported from 
>>> /path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:
>>> 
>>> Argh, this is including , which is in the std module. Can you 
>>> try removing the header "type_traits" line from the libc++ module map and 
>>> see if that helps?
>>> 
>>> I've run into this issue in the past, and I don't think that will fix it 
>>> (see below). Just to be sure, here is the output with type_traits removed 
>>> from the module map::
>>> 
>>> While building module 'Darwin' imported from /usr/include/assert.h:42:
>>> While building module 'std' imported from 
>>> /path/to/build_cmake/stage1/bin/../include/c++/v1/type_traits:211:
>>> 
>>> That's an include of . We'd need to apply this workaround to that 
>>> header too (but I think the buck stops there).
>> 
>> After commenting out the cstddef 

Re: [libcxx] r249738 - Split out of .

[Duncan P. N. Exon Smith via cfe-commits]

+Ted

> On 2015-Oct-14, at 15:32, Richard Smith via cfe-commits 
>  wrote:
> 
>> While building module 'LLVM_Utils' imported from 
>> ../lib/Support/APFloat.cpp:15:
>> In file included from :1:
>> In file included from ../include/llvm/ADT/APFloat.h:20:
>> In file included from ../include/llvm/ADT/APInt.h:19:
>> In file included from ../include/llvm/ADT/ArrayRef.h:14:
>> In file included from ../include/llvm/ADT/SmallVector.h:20:
>> In file included from ../include/llvm/Support/MathExtras.h:21:
>> /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/type_traits:220:8:
>>  error: redefinition of '__void_t'
>> struct __void_t { typedef void type; };
>>^
>> /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/type_traits:220:8:
>>  note: previous definition is here
>> struct __void_t { typedef void type; };
>>^
>> If there is a way to prevent Clang from going into std when building Darwin, 
>> it looks like that’d be the way to go.
> 
> There is no such way currently, but we could add one. The question is, is it 
> OK that newer versions of libc++ would only work with newer versions of Clang 
> if modules are enabled? I'm inclined to think this is fine, since Clang's 
> modules support is still advertised as being experimental, but if (say) you 
> or the Sony folks tell me you need new versions of libc++ to work with some 
> already-shipped Clang binary then we'll need to reconsider.

I think this is okay for Apple, assuming I understand it correctly: you're 
going to make it so that C++ modules only work with libc++ headers if you have 
a clang that is >= the headers.

My understanding is that we don't expect clang to be used with *newer* libc++ 
headers, just older or equal.  This kind of break is a little unfortunate, but 
probably fine.  Ted, can you confirm?
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Adrian Prantl via cfe-commits]

> On Oct 14, 2015, at 11:37 AM, Adrian Prantl via cfe-commits 
>  wrote:
> 
>> 
>> On Oct 13, 2015, at 7:43 PM, Richard Smith > > wrote:
>> 
>> On Tue, Oct 13, 2015 at 6:54 PM, Sean Silva > > wrote:
>> On Tue, Oct 13, 2015 at 6:14 PM, Richard Smith > > wrote:
>> On Tue, Oct 13, 2015 at 5:31 PM, Sean Silva > > wrote:
>> On Tue, Oct 13, 2015 at 3:17 PM, Richard Smith via cfe-commits 
>> > wrote:
>> On Tue, Oct 13, 2015 at 2:10 PM, Adrian Prantl via cfe-commits 
>> > wrote:
>> Hi Richard,
>> 
>> this commit appears to break the module self-host on Darwin.
>> 
>> When compiling the following program generated by clang’s own cmake script:
>> 
>> > #undef NDEBUG
>> > #include 
>> > #define NDEBUG
>> > #include 
>> > int main() { assert(this code is not compiled); }
>> 
>> with clang++ -std=c++11 -fmodules -fcxx-modules test.cpp
>> 
>> (You don't need -fcxx-modules here.)
>>  
>> I get
>> 
>> > While building module 'std' imported from 
>> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20
>> >  :
>> > While building module 'Darwin' imported from 
>> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39
>> >  :
>> > In file included from :98:
>> > In file included from 
>> > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/wchar.h:92:
>> > In file included from 
>> > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/_wctype.h:57:
>> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/ctype.h:33:10
>> >  : 
>> > fatal error: cyclic dependency in module 'std': std -> Darwin -> std
>> > #include <__config>
>> >  ^
>> > While building module 'std' imported from 
>> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20
>> >  :
>> > In file included from :1:
>> > In file included from 
>> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/algorithm:624
>> >  :
>> > In file included from 
>> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/initializer_list:47
>> >  :
>> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:10
>> >  : 
>> > fatal error: could not build module 'Darwin'
>> > #include 
>> >  ^
>> > In file included from test.cpp:2:
>> > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:10
>> >  : 
>> > fatal error: could not build module 'std'
>> > #include <__config>
>> >  ^
>> > 3 errors generated.
>> 
>> Let me know how I can help in diagnosing what’s going on here.
>> 
>> OK, I see what's wrong. Is this working any better for you in r250236?
>> 
>> We're still seeing:
>> 
>> While building module 'Darwin' imported from /usr/include/assert.h:42:
>> While building module 'std' imported from 
>> /path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:
>> 
>> Argh, this is including , which is in the std module. Can you 
>> try removing the header "type_traits" line from the libc++ module map and 
>> see if that helps?
>> 
>> I've run into this issue in the past, and I don't think that will fix it 
>> (see below). Just to be sure, here is the output with type_traits removed 
>> from the module map::
>> 
>> While building module 'Darwin' imported from /usr/include/assert.h:42:
>> While building module 'std' imported from 
>> /path/to/build_cmake/stage1/bin/../include/c++/v1/type_traits:211:
>> 
>> That's an include of . We'd need to apply this workaround to that 
>> header too (but I think the buck stops there).
> 
> After commenting out the cstddef module as well, the test case compiles 
> again. Should I commit that and the type_traits change to libcxx, or are you 
> working on a better fix?

To answer my previous question, removing the type_traits module allows us to 
finish all the cmake checks, but it then fails when building the LLVM_Utils 
module:

While building module 'LLVM_Utils' imported 

Re: [libcxx] r249738 - Split out of .

[Richard Smith via cfe-commits]

On Wed, Oct 14, 2015 at 2:03 PM, Adrian Prantl via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Oct 14, 2015, at 11:37 AM, Adrian Prantl via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
> On Oct 13, 2015, at 7:43 PM, Richard Smith  wrote:
>
> On Tue, Oct 13, 2015 at 6:54 PM, Sean Silva  wrote:
>
>> On Tue, Oct 13, 2015 at 6:14 PM, Richard Smith 
>> wrote:
>>
>>> On Tue, Oct 13, 2015 at 5:31 PM, Sean Silva 
>>> wrote:
>>>
 On Tue, Oct 13, 2015 at 3:17 PM, Richard Smith via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:

> On Tue, Oct 13, 2015 at 2:10 PM, Adrian Prantl via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Hi Richard,
>>
>> this commit appears to break the module self-host on Darwin.
>>
>> When compiling the following program generated by clang’s own cmake
>> script:
>>
>> > #undef NDEBUG
>> > #include 
>> > #define NDEBUG
>> > #include 
>> > int main() { assert(this code is not compiled); }
>>
>> with clang++ -std=c++11 -fmodules -fcxx-modules test.cpp
>>
>
> (You don't need -fcxx-modules here.)
>
>
>> I get
>>
>> > While building module 'std' imported from /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20
>> :
>> > While building module 'Darwin' imported from
>> /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39
>> :
>> > In file included from :98:
>> > In file included from
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/wchar.h:92:
>> > In file included from
>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/_wctype.h:57:
>
> > /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/ctype.h:33:10
>> :
>> fatal error: cyclic dependency in module 'std': std -> Darwin -> std
>> > #include <__config>
>> >  ^
>> > While building module 'std' imported from /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20
>> :
>> > In file included from :1:
>> > In file included from /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/algorithm:624
>> :
>> > In file included from /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/initializer_list:47
>> 
>> :
>> > /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:10
>> :
>> fatal error: could not build module 'Darwin'
>> > #include 
>> >  ^
>> > In file included from test.cpp:2:
>> > /Users/buildslave/adrian/
>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:10
>> :
>> fatal error: could not build module 'std'
>> > #include <__config>
>> >  ^
>> > 3 errors generated.
>>
>> Let me know how I can help in diagnosing what’s going on here.
>>
>
> OK, I see what's wrong. Is this working any better for you in r250236?
>

 We're still seeing:

 While building module 'Darwin' imported from /usr/include/assert.h:42:
 While building module 'std' imported from
 /path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:

>>>
>>> Argh, this is including , which is in the std module. Can
>>> you try removing the header "type_traits" line from the libc++ module map
>>> and see if that helps?
>>>
>>
>> I've run into this issue in the past, and I don't think that will fix it
>> (see below). Just to be sure, here is the output with type_traits removed
>> from the module map::
>>
>> While building module 'Darwin' imported from /usr/include/assert.h:42:
>> While building module 'std' imported from
>> /path/to/build_cmake/stage1/bin/../include/c++/v1/type_traits:211:
>>
>
> That's an include of . We'd need to apply this workaround to that
> header too (but I think the buck stops there).
>
>
> After commenting out the cstddef module as well, the test case compiles
> again. Should I commit that and the type_traits change to libcxx, or are
> you working on a better fix?
>
>
> To answer my previous 

Re: [libcxx] r249738 - Split out of .

[Adrian Prantl via cfe-commits]

> On Oct 14, 2015, at 5:07 PM, Richard Smith  wrote:
> 
> On Wed, Oct 14, 2015 at 3:58 PM, Adrian Prantl via cfe-commits 
> > wrote:
>> On Oct 14, 2015, at 3:32 PM, Richard Smith > > wrote:
>> 
>> On Wed, Oct 14, 2015 at 2:03 PM, Adrian Prantl via cfe-commits 
>> > wrote:
>>> On Oct 14, 2015, at 11:37 AM, Adrian Prantl via cfe-commits 
>>> > wrote:
 On Oct 13, 2015, at 7:43 PM, Richard Smith > wrote:
 
 On Tue, Oct 13, 2015 at 6:54 PM, Sean Silva > wrote:
 On Tue, Oct 13, 2015 at 6:14 PM, Richard Smith > wrote:
 On Tue, Oct 13, 2015 at 5:31 PM, Sean Silva > wrote:
 On Tue, Oct 13, 2015 at 3:17 PM, Richard Smith via cfe-commits 
 > wrote:
 On Tue, Oct 13, 2015 at 2:10 PM, Adrian Prantl via cfe-commits 
 > wrote:
 Hi Richard,
 
 this commit appears to break the module self-host on Darwin.
 
 When compiling the following program generated by clang’s own cmake script:
 
 > #undef NDEBUG
 > #include 
 > #define NDEBUG
 > #include 
 > int main() { assert(this code is not compiled); }
 
 with clang++ -std=c++11 -fmodules -fcxx-modules test.cpp
 
 (You don't need -fcxx-modules here.)
  
 I get
 
 > While building module 'std' imported from 
 > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20
 >  :
 > While building module 'Darwin' imported from 
 > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39
 >  :
 > In file included from :98:
 > In file included from 
 > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/wchar.h:92:
 > In file included from 
 > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/_wctype.h:57:
 > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/ctype.h:33:10
 >  : 
 > fatal error: cyclic dependency in module 'std': std -> Darwin -> std
 > #include <__config>
 >  ^
 > While building module 'std' imported from 
 > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20
 >  :
 > In file included from :1:
 > In file included from 
 > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/algorithm:624
 >  :
 > In file included from 
 > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/initializer_list:47
 >  
 > :
 > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:10
 >  : 
 > fatal error: could not build module 'Darwin'
 > #include 
 >  ^
 > In file included from test.cpp:2:
 > /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:10
 >  : 
 > fatal error: could not build module 'std'
 > #include <__config>
 >  ^
 > 3 errors generated.
 
 Let me know how I can help in diagnosing what’s going on here.
 
 OK, I see what's wrong. Is this working any better for you in r250236?
 
 We're still seeing:
 
 While building module 'Darwin' imported from /usr/include/assert.h:42:
 While building module 'std' imported from 
 /path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:
 
 Argh, this is including , which is in the std module. Can you 
 try removing the header "type_traits" line from the libc++ module map and 
 see if that helps?
 
 I've run into this issue in the past, and I don't think that will fix it 
 (see below). Just to be sure, here is the output with type_traits removed 
 from the module map::
 
 While 

Re: [libcxx] r249738 - Split out of .

[Ted Kremenek via cfe-commits]

> On Oct 14, 2015, at 3:49 PM, Duncan P. N. Exon Smith  
> wrote:
> 
> My understanding is that we don't expect clang to be used with *newer* libc++ 
> headers, just older or equal.  This kind of break is a little unfortunate, 
> but probably fine.  Ted, can you confirm?

On Apple platforms, we will always be shipping new clangs whenever the libc++ 
headers are updated, so I see no concerns there.  That’s pretty much in line 
with how we handle our headers + compiler changes in general at Apple.  For 
example, we rolled out new Objective-C changes in the last update that were 
widely and unconditionally adopted in our headers.  Even the Clang we released 
the previous year can no longer parse those headers because of those language 
changes.


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r249738 - Split out of .

[Richard Smith via cfe-commits]

On Wed, Oct 14, 2015 at 3:58 PM, Adrian Prantl via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Oct 14, 2015, at 3:32 PM, Richard Smith  wrote:
>
> On Wed, Oct 14, 2015 at 2:03 PM, Adrian Prantl via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> On Oct 14, 2015, at 11:37 AM, Adrian Prantl via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>> On Oct 13, 2015, at 7:43 PM, Richard Smith  wrote:
>>
>> On Tue, Oct 13, 2015 at 6:54 PM, Sean Silva 
>> wrote:
>>
>>> On Tue, Oct 13, 2015 at 6:14 PM, Richard Smith 
>>> wrote:
>>>
 On Tue, Oct 13, 2015 at 5:31 PM, Sean Silva 
 wrote:

> On Tue, Oct 13, 2015 at 3:17 PM, Richard Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> On Tue, Oct 13, 2015 at 2:10 PM, Adrian Prantl via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Hi Richard,
>>>
>>> this commit appears to break the module self-host on Darwin.
>>>
>>> When compiling the following program generated by clang’s own cmake
>>> script:
>>>
>>> > #undef NDEBUG
>>> > #include 
>>> > #define NDEBUG
>>> > #include 
>>> > int main() { assert(this code is not compiled); }
>>>
>>> with clang++ -std=c++11 -fmodules -fcxx-modules test.cpp
>>>
>>
>> (You don't need -fcxx-modules here.)
>>
>>
>>> I get
>>>
>>> > While building module 'std' imported from /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20
>>> :
>>> > While building module 'Darwin' imported from
>>> /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39
>>> :
>>> > In file included from :98:
>>> > In file included from
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/wchar.h:92:
>>> > In file included from
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/_wctype.h:57:
>>
>> > /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/ctype.h:33:10
>>> :
>>> fatal error: cyclic dependency in module 'std': std -> Darwin -> std
>>> > #include <__config>
>>> >  ^
>>> > While building module 'std' imported from /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20
>>> :
>>> > In file included from :1:
>>> > In file included from /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/algorithm:624
>>> :
>>> > In file included from /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/initializer_list:47
>>> 
>>> :
>>> > /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:10
>>> :
>>> fatal error: could not build module 'Darwin'
>>> > #include 
>>> >  ^
>>> > In file included from test.cpp:2:
>>> > /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:10
>>> :
>>> fatal error: could not build module 'std'
>>> > #include <__config>
>>> >  ^
>>> > 3 errors generated.
>>>
>>> Let me know how I can help in diagnosing what’s going on here.
>>>
>>
>> OK, I see what's wrong. Is this working any better for you in r250236?
>>
>
> We're still seeing:
>
> While building module 'Darwin' imported from /usr/include/assert.h:42:
> While building module 'std' imported from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:
>

 Argh, this is including , which is in the std module. Can
 you try removing the header "type_traits" line from the libc++ module map
 and see if that helps?

>>>
>>> I've run into this issue in the past, and I don't think that will fix it
>>> (see below). Just to be sure, here is the output with type_traits removed
>>> from the module map::
>>>
>>> While building module 'Darwin' imported from /usr/include/assert.h:42:
>>> While building module 'std' imported from
>>> /path/to/build_cmake/stage1/bin/../include/c++/v1/type_traits:211:
>>>
>>
>> That's an include of . We'd 

Re: [libcxx] r249738 - Split out of .

[Sean Silva via cfe-commits]

On Wed, Oct 14, 2015 at 3:32 PM, Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Wed, Oct 14, 2015 at 2:03 PM, Adrian Prantl via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> On Oct 14, 2015, at 11:37 AM, Adrian Prantl via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>> On Oct 13, 2015, at 7:43 PM, Richard Smith  wrote:
>>
>> On Tue, Oct 13, 2015 at 6:54 PM, Sean Silva 
>> wrote:
>>
>>> On Tue, Oct 13, 2015 at 6:14 PM, Richard Smith 
>>> wrote:
>>>
 On Tue, Oct 13, 2015 at 5:31 PM, Sean Silva 
 wrote:

> On Tue, Oct 13, 2015 at 3:17 PM, Richard Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> On Tue, Oct 13, 2015 at 2:10 PM, Adrian Prantl via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Hi Richard,
>>>
>>> this commit appears to break the module self-host on Darwin.
>>>
>>> When compiling the following program generated by clang’s own cmake
>>> script:
>>>
>>> > #undef NDEBUG
>>> > #include 
>>> > #define NDEBUG
>>> > #include 
>>> > int main() { assert(this code is not compiled); }
>>>
>>> with clang++ -std=c++11 -fmodules -fcxx-modules test.cpp
>>>
>>
>> (You don't need -fcxx-modules here.)
>>
>>
>>> I get
>>>
>>> > While building module 'std' imported from /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20
>>> :
>>> > While building module 'Darwin' imported from
>>> /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39
>>> :
>>> > In file included from :98:
>>> > In file included from
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/wchar.h:92:
>>> > In file included from
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/_wctype.h:57:
>>
>> > /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/ctype.h:33:10
>>> :
>>> fatal error: cyclic dependency in module 'std': std -> Darwin -> std
>>> > #include <__config>
>>> >  ^
>>> > While building module 'std' imported from /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20
>>> :
>>> > In file included from :1:
>>> > In file included from /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/algorithm:624
>>> :
>>> > In file included from /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/initializer_list:47
>>> 
>>> :
>>> > /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:10
>>> :
>>> fatal error: could not build module 'Darwin'
>>> > #include 
>>> >  ^
>>> > In file included from test.cpp:2:
>>> > /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:10
>>> :
>>> fatal error: could not build module 'std'
>>> > #include <__config>
>>> >  ^
>>> > 3 errors generated.
>>>
>>> Let me know how I can help in diagnosing what’s going on here.
>>>
>>
>> OK, I see what's wrong. Is this working any better for you in r250236?
>>
>
> We're still seeing:
>
> While building module 'Darwin' imported from /usr/include/assert.h:42:
> While building module 'std' imported from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:
>

 Argh, this is including , which is in the std module. Can
 you try removing the header "type_traits" line from the libc++ module map
 and see if that helps?

>>>
>>> I've run into this issue in the past, and I don't think that will fix it
>>> (see below). Just to be sure, here is the output with type_traits removed
>>> from the module map::
>>>
>>> While building module 'Darwin' imported from /usr/include/assert.h:42:
>>> While building module 'std' imported from
>>> /path/to/build_cmake/stage1/bin/../include/c++/v1/type_traits:211:
>>>
>>
>> That's an include of . We'd need to apply this workaround to
>> that header too (but I think the buck stops 

Re: [libcxx] r249738 - Split out of .

[Richard Smith via cfe-commits]

On Tue, Oct 13, 2015 at 6:54 PM, Sean Silva  wrote:

> On Tue, Oct 13, 2015 at 6:14 PM, Richard Smith 
> wrote:
>
>> On Tue, Oct 13, 2015 at 5:31 PM, Sean Silva 
>> wrote:
>>
>>> On Tue, Oct 13, 2015 at 3:17 PM, Richard Smith via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 On Tue, Oct 13, 2015 at 2:10 PM, Adrian Prantl via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:

> Hi Richard,
>
> this commit appears to break the module self-host on Darwin.
>
> When compiling the following program generated by clang’s own cmake
> script:
>
> > #undef NDEBUG
> > #include 
> > #define NDEBUG
> > #include 
> > int main() { assert(this code is not compiled); }
>
> with clang++ -std=c++11 -fmodules -fcxx-modules test.cpp
>

 (You don't need -fcxx-modules here.)


> I get
>
> > While building module 'std' imported from /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:
> > While building module 'Darwin' imported from
> /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:
> > In file included from :98:
> > In file included from
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/wchar.h:92:
> > In file included from
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/_wctype.h:57:

 > /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/ctype.h:33:10:
> fatal error: cyclic dependency in module 'std': std -> Darwin -> std
> > #include <__config>
> >  ^
> > While building module 'std' imported from /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:
> > In file included from :1:
> > In file included from /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/algorithm:624:
> > In file included from /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/initializer_list:47
> :
> > /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:10:
> fatal error: could not build module 'Darwin'
> > #include 
> >  ^
> > In file included from test.cpp:2:
> > /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:10:
> fatal error: could not build module 'std'
> > #include <__config>
> >  ^
> > 3 errors generated.
>
> Let me know how I can help in diagnosing what’s going on here.
>

 OK, I see what's wrong. Is this working any better for you in r250236?

>>>
>>> We're still seeing:
>>>
>>> While building module 'Darwin' imported from /usr/include/assert.h:42:
>>> While building module 'std' imported from
>>> /path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:
>>>
>>
>> Argh, this is including , which is in the std module. Can
>> you try removing the header "type_traits" line from the libc++ module map
>> and see if that helps?
>>
>
> I've run into this issue in the past, and I don't think that will fix it
> (see below). Just to be sure, here is the output with type_traits removed
> from the module map::
>
> While building module 'Darwin' imported from /usr/include/assert.h:42:
> While building module 'std' imported from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/type_traits:211:
>

That's an include of . We'd need to apply this workaround to that
header too (but I think the buck stops there).

In file included from :1:
> In file included from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/algorithm:624:
> In file included from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/initializer_list:47:
> In file included from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/cstddef:43:
> /path/to/build_cmake/stage1/bin/../include/c++/v1/stddef.h:46:15: fatal
> error: cyclic dependency in module 'Darwin': Darwin -> std -> Darwin
> #include_next 
>   ^
> While building module 'Darwin' imported from /usr/include/assert.h:42:
> In file included from :80:
> In file included from
> /path/to/build_cmake/stage1/bin/../lib/clang/3.8.0/include/tgmath.h:29:
> In file included from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:
> /path/to/build_cmake/stage1/bin/../include/c++/v1/type_traits:211:10:
> fatal error: could not build module 'std'
> #include 
>  ^
> In file included from modules.cpp:2:
> In file included from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/cassert:21:
> /usr/include/assert.h:42:10: fatal error: could not build module 'Darwin'
> #include 
>  ^
> 3 errors generated.
>
>
>
>> What we really need here 

Re: [libcxx] r249738 - Split out of .

[Adrian Prantl via cfe-commits]

Hi Richard,

this commit appears to break the module self-host on Darwin.

When compiling the following program generated by clang’s own cmake script:

> #undef NDEBUG
> #include 
> #define NDEBUG
> #include 
> int main() { assert(this code is not compiled); }

with clang++ -std=c++11 -fmodules -fcxx-modules test.cpp
I get 

> While building module 'std' imported from 
> /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:
> While building module 'Darwin' imported from 
> /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:
> In file included from :98:
> In file included from 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/wchar.h:92:
> In file included from 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/_wctype.h:57:
> /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/ctype.h:33:10:
>  fatal error: cyclic dependency in module 'std': std -> Darwin -> std
> #include <__config>
>  ^
> While building module 'std' imported from 
> /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:
> In file included from :1:
> In file included from 
> /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/algorithm:624:
> In file included from 
> /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/initializer_list:47:
> /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:10:
>  fatal error: could not build module 'Darwin'
> #include 
>  ^
> In file included from test.cpp:2:
> /Users/buildslave/adrian/llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:10:
>  fatal error: could not build module 'std'
> #include <__config>
>  ^
> 3 errors generated.

Let me know how I can help in diagnosing what’s going on here.
Once this works, I’d like to to set up a green dragon bot that builds clang 
with LLVM_ENABLE_MODULES to catch similar problems earlier.

-- adrian

> On Oct 8, 2015, at 1:36 PM, Richard Smith via cfe-commits 
>  wrote:
> 
> Author: rsmith
> Date: Thu Oct  8 15:36:30 2015
> New Revision: 249738
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=249738=rev
> Log:
> Split  out of .
> 
> Added:
>libcxx/trunk/include/ctype.h
>  - copied, changed from r249736, libcxx/trunk/include/cctype
> Modified:
>libcxx/trunk/include/cctype
>libcxx/trunk/test/std/strings/c.strings/cctype.pass.cpp
> 
> Modified: libcxx/trunk/include/cctype
> URL: 
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/cctype?rev=249738=249737=249738=diff
> ==
> --- libcxx/trunk/include/cctype (original)
> +++ libcxx/trunk/include/cctype Thu Oct  8 15:36:30 2015
> @@ -37,10 +37,6 @@ int toupper(int c);
> 
> #include <__config>
> #include 
> -#if defined(_LIBCPP_MSVCRT)
> -#include "support/win32/support.h"
> -#include "support/win32/locale_win32.h"
> -#endif // _LIBCPP_MSVCRT
> 
> #if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
> #pragma GCC system_header
> @@ -48,33 +44,19 @@ int toupper(int c);
> 
> _LIBCPP_BEGIN_NAMESPACE_STD
> 
> -#undef isalnum
> using ::isalnum;
> -#undef isalpha
> using ::isalpha;
> -#undef isblank
> using ::isblank;
> -#undef iscntrl
> using ::iscntrl;
> -#undef isdigit
> using ::isdigit;
> -#undef isgraph
> using ::isgraph;
> -#undef islower
> using ::islower;
> -#undef isprint
> using ::isprint;
> -#undef ispunct
> using ::ispunct;
> -#undef isspace
> using ::isspace;
> -#undef isupper
> using ::isupper;
> -#undef isxdigit
> using ::isxdigit;
> -#undef tolower
> using ::tolower;
> -#undef toupper
> using ::toupper;
> 
> _LIBCPP_END_NAMESPACE_STD
> 
> Copied: libcxx/trunk/include/ctype.h (from r249736, 
> libcxx/trunk/include/cctype)
> URL: 
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/ctype.h?p2=libcxx/trunk/include/ctype.h=libcxx/trunk/include/cctype=249736=249738=249738=diff
> ==
> --- libcxx/trunk/include/cctype (original)
> +++ libcxx/trunk/include/ctype.h Thu Oct  8 15:36:30 2015
> @@ -1,5 +1,5 @@
> // -*- C++ -*-
> -//=== cctype 
> --===//
> +//=== ctype.h 
> -===//
> //
> // The LLVM Compiler Infrastructure
> //
> @@ -8,14 +8,11 @@
> //
> //===--===//
> 
> -#ifndef _LIBCPP_CCTYPE
> -#define _LIBCPP_CCTYPE
> +#ifndef _LIBCPP_CTYPE_H
> +#define _LIBCPP_CTYPE_H
> 
> /*
> -cctype synopsis
> -
> -namespace std
> -{
> +ctype.h synopsis
> 
> int isalnum(int c);
> int isalpha(int c);
> @@ -31,52 +28,41 @@ int isupper(int c);

Re: [libcxx] r249738 - Split out of .

[Richard Smith via cfe-commits]

On Tue, Oct 13, 2015 at 2:10 PM, Adrian Prantl via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Hi Richard,
>
> this commit appears to break the module self-host on Darwin.
>
> When compiling the following program generated by clang’s own cmake script:
>
> > #undef NDEBUG
> > #include 
> > #define NDEBUG
> > #include 
> > int main() { assert(this code is not compiled); }
>
> with clang++ -std=c++11 -fmodules -fcxx-modules test.cpp
>

(You don't need -fcxx-modules here.)


> I get
>
> > While building module 'std' imported from /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:
> > While building module 'Darwin' imported from /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:
> > In file included from :98:
> > In file included from
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/wchar.h:92:
> > In file included from
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/_wctype.h:57:

> /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/ctype.h:33:10: fatal
> error: cyclic dependency in module 'std': std -> Darwin -> std
> > #include <__config>
> >  ^
> > While building module 'std' imported from /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:
> > In file included from :1:
> > In file included from /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/algorithm:624:
> > In file included from /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/initializer_list:47:
> > /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:10: fatal
> error: could not build module 'Darwin'
> > #include 
> >  ^
> > In file included from test.cpp:2:
> > /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:10: fatal
> error: could not build module 'std'
> > #include <__config>
> >  ^
> > 3 errors generated.
>
> Let me know how I can help in diagnosing what’s going on here.
>

OK, I see what's wrong. Is this working any better for you in r250236?


> Once this works, I’d like to to set up a green dragon bot that builds
> clang with LLVM_ENABLE_MODULES to catch similar problems earlier.
>
> -- adrian
>
> > On Oct 8, 2015, at 1:36 PM, Richard Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
> >
> > Author: rsmith
> > Date: Thu Oct  8 15:36:30 2015
> > New Revision: 249738
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=249738=rev
> > Log:
> > Split  out of .
> >
> > Added:
> >libcxx/trunk/include/ctype.h
> >  - copied, changed from r249736, libcxx/trunk/include/cctype
> > Modified:
> >libcxx/trunk/include/cctype
> >libcxx/trunk/test/std/strings/c.strings/cctype.pass.cpp
> >
> > Modified: libcxx/trunk/include/cctype
> > URL:
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/cctype?rev=249738=249737=249738=diff
> >
> ==
> > --- libcxx/trunk/include/cctype (original)
> > +++ libcxx/trunk/include/cctype Thu Oct  8 15:36:30 2015
> > @@ -37,10 +37,6 @@ int toupper(int c);
> >
> > #include <__config>
> > #include 
> > -#if defined(_LIBCPP_MSVCRT)
> > -#include "support/win32/support.h"
> > -#include "support/win32/locale_win32.h"
> > -#endif // _LIBCPP_MSVCRT
> >
> > #if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
> > #pragma GCC system_header
> > @@ -48,33 +44,19 @@ int toupper(int c);
> >
> > _LIBCPP_BEGIN_NAMESPACE_STD
> >
> > -#undef isalnum
> > using ::isalnum;
> > -#undef isalpha
> > using ::isalpha;
> > -#undef isblank
> > using ::isblank;
> > -#undef iscntrl
> > using ::iscntrl;
> > -#undef isdigit
> > using ::isdigit;
> > -#undef isgraph
> > using ::isgraph;
> > -#undef islower
> > using ::islower;
> > -#undef isprint
> > using ::isprint;
> > -#undef ispunct
> > using ::ispunct;
> > -#undef isspace
> > using ::isspace;
> > -#undef isupper
> > using ::isupper;
> > -#undef isxdigit
> > using ::isxdigit;
> > -#undef tolower
> > using ::tolower;
> > -#undef toupper
> > using ::toupper;
> >
> > _LIBCPP_END_NAMESPACE_STD
> >
> > Copied: libcxx/trunk/include/ctype.h (from r249736,
> libcxx/trunk/include/cctype)
> > URL:
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/ctype.h?p2=libcxx/trunk/include/ctype.h=libcxx/trunk/include/cctype=249736=249738=249738=diff
> >
> ==
> > --- libcxx/trunk/include/cctype (original)
> > +++ libcxx/trunk/include/ctype.h Thu Oct  8 15:36:30 2015
> > @@ -1,5 +1,5 @@
> > // -*- C++ -*-
> > -//=== cctype
> --===//
> > +//=== ctype.h
> -===//
> > //
> > //

Re: [libcxx] r249738 - Split out of .

[Richard Smith via cfe-commits]

On Tue, Oct 13, 2015 at 5:31 PM, Sean Silva  wrote:

> On Tue, Oct 13, 2015 at 3:17 PM, Richard Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> On Tue, Oct 13, 2015 at 2:10 PM, Adrian Prantl via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Hi Richard,
>>>
>>> this commit appears to break the module self-host on Darwin.
>>>
>>> When compiling the following program generated by clang’s own cmake
>>> script:
>>>
>>> > #undef NDEBUG
>>> > #include 
>>> > #define NDEBUG
>>> > #include 
>>> > int main() { assert(this code is not compiled); }
>>>
>>> with clang++ -std=c++11 -fmodules -fcxx-modules test.cpp
>>>
>>
>> (You don't need -fcxx-modules here.)
>>
>>
>>> I get
>>>
>>> > While building module 'std' imported from /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:
>>> > While building module 'Darwin' imported from /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:
>>> > In file included from :98:
>>> > In file included from
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/wchar.h:92:
>>> > In file included from
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/_wctype.h:57:
>>
>> > /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/ctype.h:33:10:
>>> fatal error: cyclic dependency in module 'std': std -> Darwin -> std
>>> > #include <__config>
>>> >  ^
>>> > While building module 'std' imported from /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:
>>> > In file included from :1:
>>> > In file included from /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/algorithm:624:
>>> > In file included from /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/initializer_list:47:
>>> > /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:10:
>>> fatal error: could not build module 'Darwin'
>>> > #include 
>>> >  ^
>>> > In file included from test.cpp:2:
>>> > /Users/buildslave/adrian/
>>> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:10:
>>> fatal error: could not build module 'std'
>>> > #include <__config>
>>> >  ^
>>> > 3 errors generated.
>>>
>>> Let me know how I can help in diagnosing what’s going on here.
>>>
>>
>> OK, I see what's wrong. Is this working any better for you in r250236?
>>
>
> We're still seeing:
>
> While building module 'Darwin' imported from /usr/include/assert.h:42:
> While building module 'std' imported from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:
>

Argh, this is including , which is in the std module. Can you
try removing the header "type_traits" line from the libc++ module map and
see if that helps?

What we really need here is a way to get the Darwin blah.h headers to only
include each other, and not find the libc++ headers. Do you need something
that works with new libc++ and old Clang, or would a Clang feature to
prevent the Darwin module from finding the std module's headers work for
you?


> In file included from :1:
> In file included from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/algorithm:624:
> In file included from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/initializer_list:47:
> In file included from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/cstddef:43:
> /path/to/build_cmake/stage1/bin/../include/c++/v1/stddef.h:46:15: fatal
> error: cyclic dependency in module 'Darwin': Darwin -> std -> Darwin
> #include_next 
>   ^
> While building module 'Darwin' imported from /usr/include/assert.h:42:
> In file included from :80:
> In file included from
> /path/to/build_cmake/stage1/bin/../lib/clang/3.8.0/include/tgmath.h:29:
> /path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:10: fatal
> error: could not build module 'std'
> #include 
>  ^
> In file included from modules.cpp:2:
> In file included from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/cassert:21:
> /usr/include/assert.h:42:10: fatal error: could not build module 'Darwin'
> #include 
>  ^
> 3 errors generated.
>
>
> Looks like the system headers are being interposed.
>
> -- Sean Silva
>
>
>>
>>
>>> Once this works, I’d like to to set up a green dragon bot that builds
>>> clang with LLVM_ENABLE_MODULES to catch similar problems earlier.
>>>
>>> -- adrian
>>>
>>> > On Oct 8, 2015, at 1:36 PM, Richard Smith via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>> >
>>> > Author: rsmith
>>> > Date: Thu Oct  8 15:36:30 2015
>>> > New Revision: 249738
>>> >
>>> > URL: http://llvm.org/viewvc/llvm-project?rev=249738=rev
>>> > Log:
>>> > Split  out of .
>>> >
>>> > Added:
>>> >libcxx/trunk/include/ctype.h
>>> >  - copied, changed from r249736, 

Re: [libcxx] r249738 - Split out of .

[Sean Silva via cfe-commits]

On Tue, Oct 13, 2015 at 6:54 PM, Sean Silva  wrote:

>
>
> On Tue, Oct 13, 2015 at 6:14 PM, Richard Smith 
> wrote:
>
>> On Tue, Oct 13, 2015 at 5:31 PM, Sean Silva 
>> wrote:
>>
>>> On Tue, Oct 13, 2015 at 3:17 PM, Richard Smith via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 On Tue, Oct 13, 2015 at 2:10 PM, Adrian Prantl via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:

> Hi Richard,
>
> this commit appears to break the module self-host on Darwin.
>
> When compiling the following program generated by clang’s own cmake
> script:
>
> > #undef NDEBUG
> > #include 
> > #define NDEBUG
> > #include 
> > int main() { assert(this code is not compiled); }
>
> with clang++ -std=c++11 -fmodules -fcxx-modules test.cpp
>

 (You don't need -fcxx-modules here.)


> I get
>
> > While building module 'std' imported from /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:
> > While building module 'Darwin' imported from
> /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:
> > In file included from :98:
> > In file included from
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/wchar.h:92:
> > In file included from
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/_wctype.h:57:

 > /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/ctype.h:33:10:
> fatal error: cyclic dependency in module 'std': std -> Darwin -> std
> > #include <__config>
> >  ^
> > While building module 'std' imported from /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:
> > In file included from :1:
> > In file included from /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/algorithm:624:
> > In file included from /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/initializer_list:47
> :
> > /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/cstddef:39:10:
> fatal error: could not build module 'Darwin'
> > #include 
> >  ^
> > In file included from test.cpp:2:
> > /Users/buildslave/adrian/
> llvm.org/_build.ninja.release/bin/../include/c++/v1/cassert:20:10:
> fatal error: could not build module 'std'
> > #include <__config>
> >  ^
> > 3 errors generated.
>
> Let me know how I can help in diagnosing what’s going on here.
>

 OK, I see what's wrong. Is this working any better for you in r250236?

>>>
>>> We're still seeing:
>>>
>>> While building module 'Darwin' imported from /usr/include/assert.h:42:
>>> While building module 'std' imported from
>>> /path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:
>>>
>>
>> Argh, this is including , which is in the std module. Can
>> you try removing the header "type_traits" line from the libc++ module map
>> and see if that helps?
>>
>
> I've run into this issue in the past, and I don't think that will fix it
> (see below). Just to be sure, here is the output with type_traits removed
> from the module map::
>
> While building module 'Darwin' imported from /usr/include/assert.h:42:
> While building module 'std' imported from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/type_traits:211:
> In file included from :1:
> In file included from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/algorithm:624:
> In file included from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/initializer_list:47:
> In file included from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/cstddef:43:
> /path/to/build_cmake/stage1/bin/../include/c++/v1/stddef.h:46:15: fatal
> error: cyclic dependency in module 'Darwin': Darwin -> std -> Darwin
> #include_next 
>   ^
> While building module 'Darwin' imported from /usr/include/assert.h:42:
> In file included from :80:
> In file included from
> /path/to/build_cmake/stage1/bin/../lib/clang/3.8.0/include/tgmath.h:29:
> In file included from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/math.h:309:
> /path/to/build_cmake/stage1/bin/../include/c++/v1/type_traits:211:10:
> fatal error: could not build module 'std'
> #include 
>  ^
> In file included from modules.cpp:2:
> In file included from
> /path/to/build_cmake/stage1/bin/../include/c++/v1/cassert:21:
> /usr/include/assert.h:42:10: fatal error: could not build module 'Darwin'
> #include 
>  ^
> 3 errors generated.
>
>
>
>> What we really need here is a way to get the Darwin blah.h headers to
>> only include each other, and not find the libc++ headers. Do you 

[libcxx] r249738 - Split out of .

[Richard Smith via cfe-commits]

Author: rsmith
Date: Thu Oct  8 15:36:30 2015
New Revision: 249738

URL: http://llvm.org/viewvc/llvm-project?rev=249738=rev
Log:
Split  out of .

Added:
libcxx/trunk/include/ctype.h
  - copied, changed from r249736, libcxx/trunk/include/cctype
Modified:
libcxx/trunk/include/cctype
libcxx/trunk/test/std/strings/c.strings/cctype.pass.cpp

Modified: libcxx/trunk/include/cctype
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/cctype?rev=249738=249737=249738=diff
==
--- libcxx/trunk/include/cctype (original)
+++ libcxx/trunk/include/cctype Thu Oct  8 15:36:30 2015
@@ -37,10 +37,6 @@ int toupper(int c);
 
 #include <__config>
 #include 
-#if defined(_LIBCPP_MSVCRT)
-#include "support/win32/support.h"
-#include "support/win32/locale_win32.h"
-#endif // _LIBCPP_MSVCRT
 
 #if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
 #pragma GCC system_header
@@ -48,33 +44,19 @@ int toupper(int c);
 
 _LIBCPP_BEGIN_NAMESPACE_STD
 
-#undef isalnum
 using ::isalnum;
-#undef isalpha
 using ::isalpha;
-#undef isblank
 using ::isblank;
-#undef iscntrl
 using ::iscntrl;
-#undef isdigit
 using ::isdigit;
-#undef isgraph
 using ::isgraph;
-#undef islower
 using ::islower;
-#undef isprint
 using ::isprint;
-#undef ispunct
 using ::ispunct;
-#undef isspace
 using ::isspace;
-#undef isupper
 using ::isupper;
-#undef isxdigit
 using ::isxdigit;
-#undef tolower
 using ::tolower;
-#undef toupper
 using ::toupper;
 
 _LIBCPP_END_NAMESPACE_STD

Copied: libcxx/trunk/include/ctype.h (from r249736, libcxx/trunk/include/cctype)
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/ctype.h?p2=libcxx/trunk/include/ctype.h=libcxx/trunk/include/cctype=249736=249738=249738=diff
==
--- libcxx/trunk/include/cctype (original)
+++ libcxx/trunk/include/ctype.h Thu Oct  8 15:36:30 2015
@@ -1,5 +1,5 @@
 // -*- C++ -*-
-//=== cctype 
--===//
+//=== ctype.h 
-===//
 //
 // The LLVM Compiler Infrastructure
 //
@@ -8,14 +8,11 @@
 //
 
//===--===//
 
-#ifndef _LIBCPP_CCTYPE
-#define _LIBCPP_CCTYPE
+#ifndef _LIBCPP_CTYPE_H
+#define _LIBCPP_CTYPE_H
 
 /*
-cctype synopsis
-
-namespace std
-{
+ctype.h synopsis
 
 int isalnum(int c);
 int isalpha(int c);
@@ -31,52 +28,41 @@ int isupper(int c);
 int isxdigit(int c);
 int tolower(int c);
 int toupper(int c);
-
-}  // std
 */
 
 #include <__config>
-#include 
-#if defined(_LIBCPP_MSVCRT)
-#include "support/win32/support.h"
-#include "support/win32/locale_win32.h"
-#endif // _LIBCPP_MSVCRT
+#include_next 
 
 #if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
 #pragma GCC system_header
 #endif
 
-_LIBCPP_BEGIN_NAMESPACE_STD
+#ifdef __cplusplus
+
+#if defined(_LIBCPP_MSVCRT)
+// We support including .h headers inside 'extern "C"' contexts, so switch
+// back to C++ linkage before including these C++ headers.
+extern "C++" {
+  #include "support/win32/support.h"
+  #include "support/win32/locale_win32.h"
+}
+#endif // _LIBCPP_MSVCRT
 
 #undef isalnum
-using ::isalnum;
 #undef isalpha
-using ::isalpha;
 #undef isblank
-using ::isblank;
 #undef iscntrl
-using ::iscntrl;
 #undef isdigit
-using ::isdigit;
 #undef isgraph
-using ::isgraph;
 #undef islower
-using ::islower;
 #undef isprint
-using ::isprint;
 #undef ispunct
-using ::ispunct;
 #undef isspace
-using ::isspace;
 #undef isupper
-using ::isupper;
 #undef isxdigit
-using ::isxdigit;
 #undef tolower
-using ::tolower;
 #undef toupper
-using ::toupper;
 
-_LIBCPP_END_NAMESPACE_STD
+#endif
 
-#endif  // _LIBCPP_CCTYPE
+#endif  // _LIBCPP_CTYPE_H

Modified: libcxx/trunk/test/std/strings/c.strings/cctype.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/strings/c.strings/cctype.pass.cpp?rev=249738=249737=249738=diff
==
--- libcxx/trunk/test/std/strings/c.strings/cctype.pass.cpp (original)
+++ libcxx/trunk/test/std/strings/c.strings/cctype.pass.cpp Thu Oct  8 15:36:30 
2015
@@ -86,18 +86,18 @@ int main()
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 
-assert(isalnum('a'));
-assert(isalpha('a'));
-assert(isblank(' '));
-assert(!iscntrl(' '));
-assert(!isdigit('a'));
-assert(isgraph('a'));
-assert(islower('a'));
-assert(isprint('a'));
-assert(!ispunct('a'));
-assert(!isspace('a'));
-assert(!isupper('a'));
-assert(isxdigit('a'));
-assert(tolower('A') == 'a');
-assert(toupper('a') == 'A');
+assert(std::isalnum('a'));
+assert(std::isalpha('a'));
+assert(std::isblank(' '));
+assert(!std::iscntrl(' '));
+