Page MenuHomePhabricator

[LLDB] Disable MSVC warning C4190
ClosedPublic

Authored by aganea on Nov 28 2019, 9:25 AM.

Details

Summary

Before this patch, when compiling with MSVC 15.9.17 (latest), we would see:

F:\llvm-project\lldb\source\Plugins\ScriptInterpreter\Python\ScriptInterpreterPython.cpp(83): warning C4190: 'LLDBSwigPythonBreakpointCallbackFunction' has C-linkage specified, but returns UDT 'llvm::Expected<bool>' which is incompatible with C

Diff Detail

Event Timeline

aganea created this revision.Nov 28 2019, 9:25 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 28 2019, 9:25 AM
aganea updated this revision to Diff 231455.Nov 28 2019, 11:00 AM
This revision is now accepted and ready to land.Dec 2 2019, 10:15 AM
This revision was automatically updated to reflect the committed changes.

Hi @aganea, I'm a but curious about this change - how did you manage to make this work with MSVC? In my experience, this construct doesn't produce warning C4190 (which this silences) with MSVC, but produces error C2526 (which I don't think can be silenced).

See e.g. https://gcc.godbolt.org/z/s1Mr6dPr5 for an example of this construct, which fails with MSVC. (It seems to fail in the same way with all versions ranging from 2010 to 2019.)

aganea added a comment.May 6 2021, 1:56 PM

Hello @mstorsjo! I've reverted the patch locally, I'm at this commit:

F:\aganea\llvm-project>git log
commit a3a8a1a15b524d91b5308db68e9d293b34cd88dd (HEAD -> main, origin/main)

Using:

F:\aganea\llvm-project>cl
Microsoft (R) C/C++ Optimizing Compiler Version 19.28.29914 for x64

that is, Visual Studio 16.9.4 running a "x64 Native Tools Command Prompt for VS 2019".

Building with:

cmake "-DLLVM_LIT_ARGS=-sv -j 36" -GNinja -DLLVM_ENABLE_PROJECTS=llvm;clang;lld;lldb -DLLVM_ENABLE_LIBXML2=OFF -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON %ROOT%/llvm -DLLVM_OPTIMIZED_TABLEGEN=ON -DCMAKE_C_COMPILER=cl -DCMAKE_CXX_COMPILER=cl -DCMAKE_LINKER=link

The invocation:

[4/10] C:\PROGRA~2\MICROS~4\2019\PROFES~1\VC\Tools\MSVC\1428~1.299\bin\Hostx64\x64\cl.exe  /nologo /TP -DGTEST_HAS_RTTI=0 -DLLDB_PYTHON_RELATIVE_LIBDIR=\"Lib/site-packages\" -DUNICODE -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_ENABLE_EXTENDED_ALIGNED_STORAGE -D_HAS_EXCEPTIONS=0 -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools\lldb\source\Plugins\ScriptInterpreter\Python -IF:\aganea\llvm-project\lldb\source\Plugins\ScriptInterpreter\Python -Itools\lldb\source -IF:\aganea\llvm-project\lldb\include -Itools\lldb\include -Iinclude -IF:\aganea\llvm-project\llvm\include -I"C:\Program Files\Python39\include" -IF:\aganea\llvm-project\llvm\..\clang\include -Itools\lldb\..\clang\include -IF:\aganea\llvm-project\lldb\source\. /DWIN32 /D_WINDOWS   /Zc:inline /Zc:__cplusplus /Zc:strictStrings /Oi /Zc:rvalueCast /bigobj /W4 -wd4141 -wd4146 -wd4244 -wd4267 -wd4291 -wd4351 -wd4456 -wd4457 -wd4458 -wd4459 -wd4503 -wd4624 -wd4722 -wd4100 -wd4127 -wd4512 -wd4505 -wd4610 -wd4510 -wd4702 -wd4245 -wd4706 -wd4310 -wd4701 -wd4703 -wd4389 -wd4611 -wd4805 -wd4204 -wd4577 -wd4091 -wd4592 -wd4319 -wd4709 -wd4324 -w14062 -we4238 /Gw /MD /O2 /Ob2   -wd4018 -wd4068 -wd4150 -wd4201 -wd4251 -wd4521 -wd4530  /EHs-c- /GR- -UNDEBUG -std:c++14 /showIncludes /Fotools\lldb\source\Plugins\ScriptInterpreter\Python\CMakeFiles\lldbPluginScriptInterpreterPython.dir\ScriptInterpreterPython.cpp.obj /Fdtools\lldb\source\Plugins\ScriptInterpreter\Python\CMakeFiles\lldbPluginScriptInterpreterPython.dir\lldbPluginScriptInterpreterPython.pdb /FS -c F:\aganea\llvm-project\lldb\source\Plugins\ScriptInterpreter\Python\ScriptInterpreterPython.cpp
F:\aganea\llvm-project\lldb\source\Plugins\ScriptInterpreter\Python\ScriptInterpreterPython.cpp(83): warning C4190: 'LLDBSwigPythonBreakpointCallbackFunction' has C-linkage specified, but returns UDT 'llvm::Expected<bool>' which is incompatible with C
F:\aganea\llvm-project\lldb\source\Plugins\ScriptInterpreter\Python\PythonDataObjects.h(355): note: see declaration of 'llvm::Expected<bool>'

Hello @mstorsjo! I've reverted the patch locally, I'm at this commit:

F:\aganea\llvm-project>git log
commit a3a8a1a15b524d91b5308db68e9d293b34cd88dd (HEAD -> main, origin/main)

Using:

F:\aganea\llvm-project>cl
Microsoft (R) C/C++ Optimizing Compiler Version 19.28.29914 for x64

that is, Visual Studio 16.9.4 running a "x64 Native Tools Command Prompt for VS 2019".

Building with:

cmake "-DLLVM_LIT_ARGS=-sv -j 36" -GNinja -DLLVM_ENABLE_PROJECTS=llvm;clang;lld;lldb -DLLVM_ENABLE_LIBXML2=OFF -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON %ROOT%/llvm -DLLVM_OPTIMIZED_TABLEGEN=ON -DCMAKE_C_COMPILER=cl -DCMAKE_CXX_COMPILER=cl -DCMAKE_LINKER=link

The invocation:

[4/10] C:\PROGRA~2\MICROS~4\2019\PROFES~1\VC\Tools\MSVC\1428~1.299\bin\Hostx64\x64\cl.exe  /nologo /TP -DGTEST_HAS_RTTI=0 -DLLDB_PYTHON_RELATIVE_LIBDIR=\"Lib/site-packages\" -DUNICODE -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_ENABLE_EXTENDED_ALIGNED_STORAGE -D_HAS_EXCEPTIONS=0 -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools\lldb\source\Plugins\ScriptInterpreter\Python -IF:\aganea\llvm-project\lldb\source\Plugins\ScriptInterpreter\Python -Itools\lldb\source -IF:\aganea\llvm-project\lldb\include -Itools\lldb\include -Iinclude -IF:\aganea\llvm-project\llvm\include -I"C:\Program Files\Python39\include" -IF:\aganea\llvm-project\llvm\..\clang\include -Itools\lldb\..\clang\include -IF:\aganea\llvm-project\lldb\source\. /DWIN32 /D_WINDOWS   /Zc:inline /Zc:__cplusplus /Zc:strictStrings /Oi /Zc:rvalueCast /bigobj /W4 -wd4141 -wd4146 -wd4244 -wd4267 -wd4291 -wd4351 -wd4456 -wd4457 -wd4458 -wd4459 -wd4503 -wd4624 -wd4722 -wd4100 -wd4127 -wd4512 -wd4505 -wd4610 -wd4510 -wd4702 -wd4245 -wd4706 -wd4310 -wd4701 -wd4703 -wd4389 -wd4611 -wd4805 -wd4204 -wd4577 -wd4091 -wd4592 -wd4319 -wd4709 -wd4324 -w14062 -we4238 /Gw /MD /O2 /Ob2   -wd4018 -wd4068 -wd4150 -wd4201 -wd4251 -wd4521 -wd4530  /EHs-c- /GR- -UNDEBUG -std:c++14 /showIncludes /Fotools\lldb\source\Plugins\ScriptInterpreter\Python\CMakeFiles\lldbPluginScriptInterpreterPython.dir\ScriptInterpreterPython.cpp.obj /Fdtools\lldb\source\Plugins\ScriptInterpreter\Python\CMakeFiles\lldbPluginScriptInterpreterPython.dir\lldbPluginScriptInterpreterPython.pdb /FS -c F:\aganea\llvm-project\lldb\source\Plugins\ScriptInterpreter\Python\ScriptInterpreterPython.cpp
F:\aganea\llvm-project\lldb\source\Plugins\ScriptInterpreter\Python\ScriptInterpreterPython.cpp(83): warning C4190: 'LLDBSwigPythonBreakpointCallbackFunction' has C-linkage specified, but returns UDT 'llvm::Expected<bool>' which is incompatible with C
F:\aganea\llvm-project\lldb\source\Plugins\ScriptInterpreter\Python\PythonDataObjects.h(355): note: see declaration of 'llvm::Expected<bool>'

Thanks for testing!

Sorry, I hadn't actually tried configuring LLDB to enable python - I'm looking into a similar case in the Lua plugin (where the same construct allegedly is causing errors), and I've tried to copy that snippet from the python plugin into a separate file, and there it errors out. But when actually building the python plugin as such, it does indeed succeed. That should be enough for me to dig into the matter - thanks!

Just for the record, the issue seems to be this:

$ cat cpp-ret-c.cpp 
template<class T> class MyClass {
public:
    T a;
};
extern "C" MyClass<int> unmangledFunction();
$ cl -c cpp-ret-c.cpp 
cpp-ret-c.cpp
cpp-ret-c.cpp(5): error C2526: 'unmangledFunction': C linkage function cannot return C++ class 'MyClass<int>' 
cpp-ret-c.cpp(5): note: see declaration of 'MyClass<int>'
$ cat cpp-ret-c2.cpp 
template<class T> class MyClass {
public:
    T a;
};
MyClass<int> unusedFunc() { return MyClass<int>{0}; }
extern "C" MyClass<int> unmangledFunction();
$ cl -c cpp-ret-c2.cpp
cpp-ret-c2.cpp

So this construct, in MSVC, requires that the problematic return type template already has been instantiated somewhere else first. The case in the python plugin works, but it has been copied to the Lua plugin too, where it fails.