On Mon, Oct 24, 2016 at 4:17 PM, Richard Smith <rich...@metafoo.co.uk> wrote:
> 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.
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 <stdint.h>" to make it work.
-- example.m
#import <IOKit/IODataQueueClient.h>
--
$ 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 <module-includes>: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 <IOKit/IODataQueueClient.h>
~~~~~~~^
>
>> > 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
