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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358857 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Nico Weber
2019-04-21 17:19:27 +00:00
parent f6b23dfdd4
commit ecefdcd2b9
2 changed files with 9 additions and 8 deletions
+3 -3
View File
@@ -1079,10 +1079,10 @@ static void outputHex(OutputStream &OS, unsigned C) {
writeHexDigit(&TempBuffer[Pos--], C % 16);
C /= 16;
}
TempBuffer[Pos--] = 'x';
assert(Pos >= 0);
TempBuffer[Pos--] = '\\';
}
TempBuffer[Pos--] = 'x';
assert(Pos >= 0);
TempBuffer[Pos--] = '\\';
OS << StringView(&TempBuffer[Pos + 1]);
}