Differential D70830
[LLDB] Disable MSVC warning C4190 Authored by aganea on Nov 28 2019, 9:25 AM.
Details 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 TimelineComment Actions 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.) Comment Actions 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>' Comment Actions 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! Comment Actions 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. |