> On Oct 15, 2015, at 2:51 PM, Alex Rosenberg <al...@leftfield.org> wrote:
>
> On Oct 15, 2015, at 2:20 PM, Adrian Prantl via cfe-commits
> <cfe-commits@lists.llvm.org <mailto:cfe-commits@lists.llvm.org>> wrote:
>
>>>
>>> On Oct 15, 2015, at 2:09 PM, Adrian Prantl via cfe-commits
>>> <cfe-commits@lists.llvm.org <mailto:cfe-commits@lists.llvm.org>> wrote:
>>>
>>>>
>>>> On Oct 15, 2015, at 1:42 PM, Richard Smith <rich...@metafoo.co.uk
>>>> <mailto:rich...@metafoo.co.uk>> wrote:
>>>>
>>>> On Thu, Oct 15, 2015 at 11:14 AM, Adrian Prantl <apra...@apple.com
>>>> <mailto:apra...@apple.com>> wrote:
>>>>
>>>>> On Oct 14, 2015, at 5:07 PM, Richard Smith <rich...@metafoo.co.uk
>>>>> <mailto:rich...@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
>
> <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?
— adrian
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
