diff options
| author | Martin Storsjö <martin@martin.st> | 2021-02-22 01:13:13 +0200 |
|---|---|---|
| committer | Martin Storsjö <martin@martin.st> | 2021-03-04 08:55:27 +0200 |
| commit | c793f68d9b62e9813f17d438be5edd23f348b4b9 (patch) | |
| tree | 7617866ebc5bd483bf16518c92369bacc5cd02a0 /lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp | |
| parent | c75da238b419516534f372f87c9fd707650ebf3f (diff) | |
| download | llvm-c793f68d9b62e9813f17d438be5edd23f348b4b9.zip llvm-c793f68d9b62e9813f17d438be5edd23f348b4b9.tar.gz llvm-c793f68d9b62e9813f17d438be5edd23f348b4b9.tar.bz2 | |
[libcxx] Don't use dllimport for a static member in a template
This fixes clang warnings (that are treated as errors when running
the test suite):
libcxx/include/string:4409:59: error: definition of dllimport static field [-Werror,-Wdllimport-static-field-def]
basic_string<_CharT, _Traits, _Allocator>::npos;
The warning is normally not visible as long as the libc++ headers
are treated as system headers.
The same construct is always an error in MSVC.
(One _LIBCPP_FUNC_VIS was added in
2d8f23f571635c1fb983b40c4c2548716a5b65b6, which broke DLL builds.
59919c4d6b6370da7133bbca0d31844e21646bb1 fixed this by adding another
_LIBCPP_FUNC_VIS on the declaration for consistency, but the underlying
issue remained, that one can't use dllimport here.)
Differential Revision: https://reviews.llvm.org/D97168
Diffstat (limited to 'lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp')
0 files changed, 0 insertions, 0 deletions