Recent LLVM Build Attempt -- obj.ClangAST.vcxproj Failed to Build

Project Infrastructure LLVM Dev List Archives
1

I configured with this command:
"
cmake …/llvm -G"Visual Studio 16 2019" -A Win32 -Thost=x64 -DLLVM_ENABLE_EH=ON -DCMAKE_BUILD_TYPE=Release -DLLVM_USE_CRT_RELEASE=MT -DLLVM_ENABLE_RTTI=ON -DLLVM_ENABLE_PROJECTS=“clang;clang-tools-extra;lld;libcxx;libcxxabi” -DCMAKE_CXX_FLAGS=“/permissive- /D_SILENCE_ALL_CXX17_DEPRECATION_WARNINGS” -DCMAKE_CXX_STANDARD=17
"
and when building the target ALL_BUILD.vcxproj I redirected the output to a file. I’m attaching that file to this message. Name of the file is build.log. I’m attaching CMakeCache.txt and CMakeOutput.log for reference.

Any help is appreciated. Thanks in advance.

build.log (149 KB)

CMakeOutput.log (38 KB)

CMakeCache.txt (77.3 KB)

2

I see two interesting things in your configuration:

  • You are passing -DCMAKE_CXX_STANDARD=17. Is there a reason for that? Using fewer options is generally more likely to result in a successful build.
  • You are using MSVC build 14.23.28105. This is newer than what I am using and our bots are using. I will have to try upgrading myself.

This is the error in question isolated:
C:\llvm-project\clang\lib\AST\Interp\ByteCodeStmtGen.cpp(239,1): error C2872: ‘Optional’: ambiguous symbol [C:\llvm-project\build\tools\clang\lib\AST\obj.clangAST.vcxproj]
C:\llvm-project\clang\lib\AST\Interp\ByteCodeStmtGen.cpp(22,57): message : could be ‘Optional = llvm::Optional’ [C:\llvm-project\build\tools\clang\lib\AST\obj.clangAST.vcxproj]

This ByteCodeStmtGen.cpp file is relatively new, so that could be interesting.

3

I hope I’m not being too presumptuous or anything when I say this: could you guys please review the obj.ClangAST.vcxproj project and try to fix the ambiguity error?

Reid asked me why I’m using C++17. I just want to use the latest released standard. Most if it still compiles anyway. So I’ll stick with it.

4

From a quick glance at the build log, you should be able to avoid the ambiguity by removing the alias template

template <typename T> using Optional = llvm::Optional<T>;

from the files ByteCodeExprGen.cpp and ByteCodeStmtGen.cpp in clang/lib/AST/Interp.

Note that this is just my best guess, I didn‘t try it myself. I‘m also not sure why MSVC sees an ambiguity here.

5

I went ahead and did that in 19f1dc7. I wasn’t able to reproduce the problem locally, but I am not building through Visual Studio, I am using ninja. To build in C++17 mode, I just re-ran with -std:c++17, and got warnings but no errors.

6

I tracked this down to be dependent on the MSVC Conformance mode (“/permissive-“ flag 1, which explicitly disables certain non-conforming behavior that MSVC would accept otherwise). See the following minimal example: https://godbolt.org/z/fBaWdQ

In conforming mode, MSVC reports the ambiguity, in permissive mode it doesn’t. Clang, gcc and icc all accept the code. I think MSVC is wrong in reporting the ambiguity, since unqualified lookup inside the definition of N2::N3::f – even though f is defined outside N2::N3 – should happen scope by scope for N3, N2 and finally global. S is visible for the first time in N2 (through “using N1::S”). However, the allegedly ambiguous alias template S is only introduced in the global scope, which should not be searched at all, since we already found S in N2.

Moreover, it is interesting to note that if C is not a class template, MSVC accepts the code even in conforming mode: https://godbolt.org/z/O7jbq2

If my reasoning above is correct, this is a bug in MSVC under conforming mode.

Reid, thank you for your patch in 19f1dc7. Note that directly including clang/Basic/LLVM.h is not necessary, since it is already included indirectly via ByteCodeStmtGen.h. Moreover, the same alias templates are also present in ByteCodeExprGen.cpp, you might want to remove them there as well.