[libcxx] r249738 - Split <ctype.h> out of <cctype>.

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

+Ted

> On 2015-Oct-14, at 15:32, Richard Smith via cfe-commits <cfe-commits at 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?