+Ted
> On 2015-Oct-14, at 15:32, Richard Smith via cfe-commits
> <cfe-commits@lists.llvm.org> wrote:
>
>> While building module 'LLVM_Utils' imported from
>> ../lib/Support/APFloat.cpp:15:
>> In file included from <module-includes>: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
