diff options
author | Nico Weber <nicolasweber@gmx.de> | 2019-04-21 17:19:27 +0000 |
---|---|---|
committer | Nico Weber <nicolasweber@gmx.de> | 2019-04-21 17:19:27 +0000 |
commit | ce67a41741cbabf93ad981d03e1eb04c1ac1f4fb (patch) | |
tree | 1cdd25d1a79ce39757bf4b997446cd4a3fe540bb /llvm/lib/ExecutionEngine/Orc | |
parent | 8fc9902bbb0d48c75fe33627641f14c9c3e09e25 (diff) | |
download | llvm-ce67a41741cbabf93ad981d03e1eb04c1ac1f4fb.zip llvm-ce67a41741cbabf93ad981d03e1eb04c1ac1f4fb.tar.gz llvm-ce67a41741cbabf93ad981d03e1eb04c1ac1f4fb.tar.bz2 |
llvm-undname: Fix hex escapes in wchar_t, char16_t, char32_t strings
llvm-undname used to put '\x' in front of every pair of nibbles, but
u"\xD7\xFF" produces a string with 6 bytes: \xD7 \0 \xFF \0 (and \0\0). Correct
for a single character (plus terminating \0) is u\xD7FF instead.
Now, wchar_t, char16_t, and char32_t strings roundtrip from source to
clang-cl (and cl.exe) and then llvm-undname.
(...at least as long as it's not a string like L"\xD7FF" L"foo" which
gets demangled as L"\xD7FFfoo", where the compiler then considers the
"f" as part of the hex escape. That seems ok.)
Also add a comment saying that the "almost-valid" char32_t string I
added in my last commit is actually produced by compilers.
llvm-svn: 358857
Diffstat (limited to 'llvm/lib/ExecutionEngine/Orc')
0 files changed, 0 insertions, 0 deletions