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