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

[Richard Smith via cfe-commits]

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

> On Oct 15, 2015, at 2:51 PM, Alex Rosenberg <alexr at leftfield.org> wrote:
>
> On Oct 15, 2015, at 2:20 PM, Adrian Prantl via cfe-commits <
> cfe-commits at lists.llvm.org> wrote:
>
>
> On Oct 15, 2015, at 2:09 PM, Adrian Prantl via cfe-commits <
> cfe-commits at lists.llvm.org> wrote:
>
>
> On Oct 15, 2015, at 1:42 PM, Richard Smith <richard at metafoo.co.uk> wrote:
>
> On Thu, Oct 15, 2015 at 11:14 AM, Adrian Prantl <aprantl at apple.com> wrote:
>
>>
>> On Oct 14, 2015, at 5:07 PM, Richard Smith <richard at metafoo.co.uk> 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 <foo.h> 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 &F) {
> *     ^*
> *../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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20151015/37332ac6/attachment-0001.html>