diff options
author | Nat Goodspeed <nat@lindenlab.com> | 2021-10-27 13:01:37 -0400 |
---|---|---|
committer | Nat Goodspeed <nat@lindenlab.com> | 2021-10-27 13:01:37 -0400 |
commit | af5c5a994b90a27e16ef6f2f5044e096269e4217 (patch) | |
tree | b8b1c55265a02da48b92e2ec412fd79045c836b5 /indra/cmake/LLAddBuildTest.cmake | |
parent | cbaba2df56c66926e051d50b6cb02955c81c2a6c (diff) |
SL-16207: Update llstring.h handling of different string types.
In llpreprocessor.h, consider the case of clang on Windows: #define
LL_WCHAR_T_NATIVE there as well as for the Microsoft compiler with /Zc:wchar_t
switch.
In stdtypes.h, inject a LLWCHAR_IS_WCHAR_T symbol to allow the preprocessor to
make decisions about when the types are identical.
llstring.h's conversion logic deals with three types of wide strings
(LLWString, std::wstring and utf16string) based on three types of wide char
(llwchar, wchar_t and U16, respectively). Sometimes they're three distinct
types, sometimes wchar_t is identical to llwchar and sometimes wchar_t is
identical to U16. Rationalize the three cases using ll_convert_u16_alias() and
new ll_convert_wstr_alias() macros.
stringize.h was directly calling wstring_to_utf8str() and utf8str_to_wstring(),
which was producing errors with VS 2019 clang since there isn't actually a
wstring_to_utf8str(std::wstring) overload. Use ll_convert<std::string>()
instead, since that redirects to the relevant ll_convert_wide_to_string()
function. (And now you see why we've been trying to migrate to the uniform
ll_convert<target>() wrapper!) Similarly, call ll_convert<std::wstring>()
instead of a two-step conversion from utf8str_to_wstring(), producing LLWString,
then a character-by-character copy from LLWString to std::wstring. That
isn't even correct: on Windows, we should be encoding from UTF32 to UTF16.
Diffstat (limited to 'indra/cmake/LLAddBuildTest.cmake')
0 files changed, 0 insertions, 0 deletions