`private` declarations should never be allowed to carry the `@_alwaysEmitIntoClient` attribute. This has been allowed by mistake for a while, but newer compilers should make this an error.
These functions were the odd ones out in not using `encoding` for this parameter label. Harmonizing this term will also make the documentation more consistent.
This PR changes the deprecation annotation of `String.init(validatingUTF8: [CChar])` to match that of `String.init(validatingUTF8: UnsafePointer<CChar>)`. Both have been given new, undeprecated, renamed replacements (`validatingCString:`).
Resolves rdar://121674502.
After rebasing on master and incorporating more 32-bit support,
perform a bunch of cleanup, documentation updates, comments, move code
back to String declaration, etc.
This is a giant squashing of a lot of individual changes prototyping a
switch of String in Swift 5 to be natively encoded as UTF-8. It
includes what's necessary for a functional prototype, dropping some
history, but still leaves plenty of history available for future
commits.
My apologies to anyone trying to do code archeology between this
commit and the one prior. This was the lesser of evils.
The functions in LibcShims are used externally, some directly and some through @inlineable functions. These are changed to SWIFT_RUNTIME_STDLIB_SPI to better match their actual usage. Their names are also changed to add "_swift" to the front to match our naming conventions.
Three functions from SwiftObject.mm are changed to SPI and get a _swift prefix.
A few other support functions are also changed to SPI. They already had a prefix and look like they were meant to be SPI anyway. It was just hard to notice any mixup when they were #defined to the same thing.
rdar://problem/35863717
Add some fast paths to String.init(decoding:as:) for inputs of
contiguously stored UTF-8 code units. Dramatically speeds up creation
when the String happens to be ASCII and we can form more small
strings.
Streamline internal String creation. Previously, everything funneled
into a single generic function, however, every single call of the
generic funnel had relevant specific information that could be used
for a more efficient algorithm.
In preparation for efficiently forming small strings, refactor this
logic into a handful of more specialized subroutines to preserve more
specific information from the callers.
As proposed by SE-0107: UnsafeRawPointer:
https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md#cstring-conversion
Adds String.init(cString: UnsafePointer<UInt8>)
Adds String.nulTerminatedUTF8CString: ContiguousArray<CChar>
This is necessary for eliminating UnsafePointer conversion. Such
conversion is extremely common for interoperability between Swift
strings and C strings to bridge the difference between CChar and
UTF8.CodeUnit. The standard library does not provide any convenient
utilities for converting between the differently typed
buffers. These APIs will handle the simplest cases involving C
interoperability. More convenience can be added later.
[stdlib] Fix the `String.decodeCString` for UTF16 and UTF32
Resolves [SR-1578](https://bugs.swift.org/browse/SR-1578]
Essentially the problem was that `strlen` is not the right way of
obtaining a length of anything but null-terminated UTF-8 sequence of
characters. Other encodings require alternative mechanisms.
