Since the ExpressibleByStringInterpolation protocol is also deprecated
now, it makes little sense to suggest using it instead of
StringInterpolationConvertible. Instead, the message now recommends
considering an init(_:String).
See
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160808/026171.html
for some more details.
This API should have been converted to use the
new Builtin before it was introduced here:
commit a41484ea2b
Author: Andrew Trick <atrick@apple.com>
Date: Fri Jul 22 13:32:08 2016
Add UnsafeRawPointer type and API. (#3677)
But it looks like that was dropped during during some local merge. It's not
likely to be a problem until developers start adopting the new API and the
optimizer starts using TBAA aggressively. The other "raw" API's are binding
memory or using memmove, so those are safe.
rdar:23406272.
In CMake 3.4.3, if `CMP0054` policy isn't set to any value, `cmake`
uses the OLD behavior and issues a long warning message for every
`if()` statement having a quoted variable whose value is an other
variable's name.
For example,
```
set(FOO 1)
set(VAR_A FOO)
set(VAR_B BAR)
if ("${VAR_A}" STREQUAL "FOO")
endif()
if ("${VAR_B}" STREQUAL "BAR")
endif()
```
issues `CMP0054` warning message for `"${VAR_A}"` and not for
`"${VAR_B}"`.
Cygwin `cmake` defines the variable `CMAKE_SYSTEM_NAME` as `CYGWIN`
and defines the variable `CYGWIN` as 1(TRUE).
Linux `cmake` defines the variable `CMAKE_SYSTEM_NAME` as `Linux`
and there is no variable `Linux`.
So, if we didn't set any value to `CMP0054` policy, every
`if ("${CMAKE_SYSTEM_NAME}" ...)` generated long warning message in
Cygwin, but did not generate in Linux.
1. The change in StaticString's withUTF8Buffer is to store the UTF-8 code unit properly in the buffer.
2. The change in StringCore's _nthContiguous is to represent the UTF-16 data correctly when it contains the high byte.
We ran validation tests and foundation tests with the change on x86-64 and s390x. No new regression is observed.
We should not make grapheme segmentation algorithm inlineable now (and
possibly ever). The immediate reason is that Unicode 8.0 grapheme
segmentation algorithm has been changed significantly in Unicode 9.0.
Unicode 9.0 requires a stateful algorithm. Current indices and
iterators just don't have the storage for that state, so we can't mark
them as fragile.
Inlining it causes the lldb "po" command to generate a 50KB binary blob that
needs to be injected into the target process. It is much faster to just call
into the standard-library binary.
<rdar://problem/27710066>
If the Swift error wrapped in a _SwiftNativeNSError box conforms to
Hashable, the box now uses the Swift's conformance to Hashable.
Part of rdar://problem/27574348.
