[llvm-dev] Recent LLVM Build Attempt -- obj.ClangAST.vcxproj Failed to Build

Thu Oct 31 17:45:31 PDT 2019

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.

[1]: https://docs.microsoft.com/en-us/cpp/build/reference/permissive-standards-conformance?view=vs-2019

From: Reid Kleckner <rnk at google.com>
Sent: Donnerstag, 31. Oktober 2019 22:32
To: Jonathan Meier <jonathan.meier at outlook.com>
Cc: Osman Zakir <osmanzakir90 at hotmail.com>; llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] Recent LLVM Build Attempt -- obj.ClangAST.vcxproj Failed to Build

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.

On Thu, Oct 31, 2019 at 11:11 AM Jonathan Meier <jonathan.meier at outlook.com<mailto:jonathan.meier at outlook.com>> wrote:
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.

Am 31.10.2019 um 14:44 schrieb Osman Zakir via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>:

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.
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191101/88d0998f/attachment.html>