Odd error in the modules-enabled LLVM build

Hey Richard (or anyone else who wants to weigh in on this), I’m seeing something I can’t quite explain - figured I’d check if I was missing something obvious, or whether this is worth/requires more investigation.

Trying to test the modules enabled LLVM build (LLVM_ENABLE_MODULES=ON) I came across an error:

In module ‘LLVM_Utils’ imported from lib/DebugInfo/PDB/Native/ModuleDebugStream.cpp:11:
/usr/lib/gcc/x86_64-linux-gnu/7.3.0/…/…/…/…/include/c++/7.3.0/bits/shared_ptr.h:278:4: error: no matching constructor for initialization
of ‘__shared_ptrllvm::msf::MappedBlockStream
: __shared_ptr<_Tp>(std::move(__r)) { }
^ ~~~~~~~~~~~~~~

/usr/lib/gcc/x86_64-linux-gnu/7.3.0/…/…/…/…/include/c++/7.3.0/bits/shared_ptr_base.h:1157:2: note: candidate template ignored: substitution failure [with _Yp = llvm::msf::MappedBlockStream, _Del = std::default_deletellvm::msf::MappedBlockStream]: default argument of ‘_UniqCompatible’ must be imported from module ‘LLVM_DebugInfo_PDB.IPDBEnumChildren’ before it is required
__shared_ptr(unique_ptr<_Yp, _Del>&& __r)

I guess I should be using libcxx if I want to use modules, rather than using my system libstdc++? But even then, this seems like a rather strange error that may be indicative of a bug?

Including IPDBEnumChildren.h does fix the error - but it seems like a wholely unrelated header to have to include here…

  • Dave


Looks like we’re doing … something … wrong when computing visibility for a default template argument. Perhaps we’re not correctly taking into account that the lexical parent of the default template argument might have been merged with definitions from other modules (and if so, the default template argument should be considered available whenever any of the merged copies of the enclosing lexical context are visible).

I think the bug is somewhere here: https://github.com/llvm-mirror/clang/blob/master/lib/Sema/SemaLookup.cpp#L1550 (I think that comment is just wrong, and we should always be checking for any visible definition of the enclosing lexical context. But I suspect if we make that change we’ll find a test case that shows why we need something more subtle here.)