[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
>

Investigating that is ~third on my todo list at the moment. I suspect this
is a Clang bug; I don't know why we have two different SROA passes, but
ScalarReplAggregates.cpp doesn't make SROA.h visible, so the two names
should not conflict.


> What’s the appropriate solution, renaming the struct ::SROA in the
> anonymous namespace to something else?
>
> — adrian
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20151015/5db671ca/attachment.html>