nicolas/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Fixed crasher in <rdar://problem/6780904> [irgen] Assertion failed: (Result == conversionOK && "UTF-8 to UTF-16 conversion failed"), function GetAddrOfConstantCFString, file CodeGenModule.cpp, line 1063.

Browse Source 
Still a diagnostic related FIXME (will discuss with Daniel/Fariborz offline).

llvm-svn: 68975
This commit is contained in:
Steve Naroff
2009-04-13 19:08:08 +00:00
parent 1daeb69f95
commit 84073ec51f
2 changed files with 26 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
clang/lib/CodeGen/CodeGenModule.cpp
View File

@@ -1060,16 +1060,25 @@ GetAddrOfConstantCFString(const StringLiteral *Literal) {
Result = ConvertUTF8toUTF16(&FromPtr, FromPtr+Literal->getByteLength(),
&ToPtr, ToPtr+Literal->getByteLength(),
strictConversion);
assert(Result == conversionOK && "UTF-8 to UTF-16 conversion failed");
if (Result == conversionOK) {
// FIXME: Storing UTF-16 in a C string is a hack to test Unicode strings
// without doing more surgery to this routine. Since we aren't explicitly
// checking for endianness here, it's also a bug (when generating code for
// a target that doesn't match the host endianness). Modeling this as an
// i16 array is likely the cleanest solution.
StringLength = ToPtr-&ToBuf[0];
str.assign((char *)&ToBuf[0], StringLength*2);// Twice as many UTF8 chars.
isUTF16 = true;
} else if (Result == sourceIllegal) {
// FIXME: GCC currently emits the following warning (in the backend):
// "warning: input conversion stopped due to an input byte that does not
// belong to the input codeset UTF-8"
// The clang backend doesn't currently emit any warnings.
str.assign(Literal->getStrData(), Literal->getByteLength());
StringLength = str.length();
} else
assert(Result == conversionOK && "UTF-8 to UTF-16 conversion failed");
// FIXME: Storing UTF-16 in a C string is a hack to test Unicode strings
// without doing more surgery to this routine. Since we aren't explicitly
// checking for endianness here, it's also a bug (when generating code for
// a target that doesn't match the host endianness). Modeling this as an i16
// array is likely the cleanest solution.
StringLength = ToPtr-&ToBuf[0];
str.assign((char *)&ToBuf[0], StringLength*2); // Twice as many UTF8 chars.
isUTF16 = true;
} else {
str.assign(Literal->getStrData(), Literal->getByteLength());
StringLength = str.length();