Committed as r285152. On Tue, Oct 25, 2016 at 3:09 PM, Richard Smith <rich...@metafoo.co.uk> 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 <rich...@metafoo.co.uk> > 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 <rich...@metafoo.co.uk> >> 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 <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/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 <IOKit/IODataQueueClient.h> >>>> ~~~~~~~^ >>> >>> >>> 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
