[SR-466] Imported APIs taking chars should use CChar

[lhoward]

Previous ID	SR-466
Radar	None
Original Reporter	@lhoward
Type	Bug
Status	Closed
Resolution	Done

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug, ClangImporter, StarterBug
Assignee	@dduan
Priority	Medium

md5: fb3d11a5978519172603e14b926036d4

Issue Description:

I don’t know if/when Swift will be ported to a platform where the character type is unsigned but perhaps imported APIs where the character signedness is not explicitly specified should be imported as CChar rather than Int8?

Documentation says that CChar is the native character type.

[belkadan]

@DougGregor, @lattner, any opinions?

[DougGregor]

Seems reasonable to me.

[lattner]

I don't have a strong opinion on it, I was sort of hoping that all the C* types would go away someday. I agree that in this case, CChar does serve a useful purpose though.

[Dante-Broggi]

Is this resolved or no longer being considered? If so, it should be closed.

[belkadan]

I think we could still do it. It's not ABI-breaking, since the CChar typealias is fixed for each platform. (We also don't have a CSignedChar, which we'd probably want.)

[groue]

If imported APIs would expose a CChar instead of a raw Int8 or Uint8, we could avoid the illusion of a mismatch with other Swift APIs. For example, String.utf8CString returns a ContiguousArray<CChar>. If we had CChar everywhere, no one would ever wonder how to write correct platform-independent code.

This message is a follow-up of https://forums.swift.org/t/is-there-is-mismatch-between-string-utf8cstring-and-imported-c-declarations/21013

[belkadan]

Tagging as a StarterBug. All the pieces for this are in place, so what's left is:

1. Remove the entries for Char_U, Char_S, WChar_S, and WChar_U from BuiltinMappedTypes.def. These represent char and wchar_t without explicit signedness, and won't disturb signed char and unsigned char.
2. Add cases for those four types to VisitBuiltinType in ImportType.cpp. These cases should do the same thing as the ones generated for the entries in BuiltinMappedTypes.def, but without the unwrapCType call.
3. Update all the tests that change because of this.

[benrimmington]

If wchar_t will be imported as CWideChar, the typealias might need to be updated (e.g. 16-bit on Windows, I think). However, portability wouldn't be improved with CWideChar, if it uses Unicode.Scalar on Darwin, and Int16 or UInt16 on Windows.

[belkadan]

It's already using CWideChar; the only difference is that it looks through the typealias at the point of import, and now we'll be preserving the typealias. That won't change anything in the ABI.

[dduan]

I ran into this, discovered the forum post, which lead me here. #32692