Okay, that makes sense. The only issue then is that the runtime doesn't
get control over what the constant string class reference is called, but since
GNU and NeXT both use the same name that doesn't seem to be an issue.
RE: The patch:
(1) In ASTContext::getCFConstantStringType there is really no need to use
a SmallVector here, even if the size is changing by one. Also some of
the comments re: the type are incorrect... and why did you change the ones
you did (the str I understand, but why unsigned -> signed or const int* -> int*)?
I think it makes more sense to change this file when someone does UTF-16
support.
(2) The NeXT runtime should still set the section on constant cfstrings.
Okay, that makes sense. The only issue then is that the runtime doesn't
get control over what the constant string class reference is called, but since
GNU and NeXT both use the same name that doesn't seem to be an issue.
RE: The patch:
(1) In ASTContext::getCFConstantStringType there is really no need to use
a SmallVector here, even if the size is changing by one. Also some of
the comments re: the type are incorrect... and why did you change the ones
you did (the str I understand, but why unsigned -> signed or const int* -> int*)?
I think it makes more sense to change this file when someone does UTF-16
support.
This is to match closely the CoreFoundation declaration that is like this:
But if you think we should keep the previous decaration, I don't see any problem about it, as long as they are equivalents.
(2) The NeXT runtime should still set the section on constant cfstrings.
Actually, both the builtin___CFStringMakeConstantString and the objc constant string generator store cf strings into"__DATA, __cfstring" in GCC.
And so, GetAddrOfConstantCFString() already set it to this value. Do you think about something else ?
I have another question about string generation.
Actually, if you compile the code below using GCC, it create only one .ascii "Hello World !" constant and use it for both the constant string and the CFString data.
Should we implement this optimization too, or is there a reason we generate you own private c string for each CFString ?
An other version of the patch that revert back the type of the isa field to "const int *", but keep unsigned value for other fields (as CoreFoundation declare them as unsigned values).
I also drop the SmallVector to use a static array.