This documentation revision covers a large number of types & protocols:
String, its views and their indices, the Unicode codec types and protocol,
as well as Character, UnicodeScalar, and StaticString, among others.
This also includes a few small changes across the standard library for
consistency.
This revises and expands on documentation for the new collection methods
for working with indices and the revised Swift 3 set APIs. In addition,
it includes documentation for the new range types.
Swift's Dictionary and Set are typed, but when bridged to NSDictionary
and NSSet they should behave accordingly, that is, allow querying for
keys of arbitrary types.
rdar://problem/23679193
It was casting an AnyObject pointer to an Int pointer before accessing
it. This is fortunately no longer needed because theoretically it's
undefined behavior.
Implements SE-0055: https://github.com/apple/swift-evolution/blob/master/proposals/0055-optional-unsafe-pointers.md
- Add NULL as an extra inhabitant of Builtin.RawPointer (currently
hardcoded to 0 rather than being target-dependent).
- Import non-object pointers as Optional/IUO when nullable/null_unspecified
(like everything else).
- Change the type checker's *-to-pointer conversions to handle a layer of
optional.
- Use 'AutoreleasingUnsafeMutablePointer<NSError?>?' as the type of error
parameters exported to Objective-C.
- Drop NilLiteralConvertible conformance for all pointer types.
- Update the standard library and then all the tests.
I've decided to leave this commit only updating existing tests; any new
tests will come in the following commits. (That may mean some additional
implementation work to follow.)
The other major piece that's missing here is migration. I'm hoping we get
a lot of that with Swift 1.1's work for optional object references, but
I still need to investigate.
In fragile stdlib builds, _Cocoa(Set|Dictionary)Iterator is fixed
layout and we never need to use its metadata. In resilient builds,
it is resilient so the metadata is required for value witness
calls.
Unfortunately SIL doesn't have asserts for references to insufficiently
visible *types* yet, so this wasn't caught except by building benchmarks.
This is a staging attribute that will eventually mean "fixed-contents"
for structs and "closed" for enums, as described in
docs/LibraryEvolution.rst.
This is pretty much the minimal set of types that must be fixed-layout,
because SILGen makes assumptions about their lowering.
If desired, some SILGen refactoring can allow some of these to be
resilient. For example, bridging value types could be made to work
with resilient types.
This is more or less a workaround for some optimizations (mainly ARC opt) to avoid performance degradation with the upcoming inliner changes
In some situations it makes a big difference for ARC opt if a function is inlined or not, althought this shouldn't be the case.
When we're not serializing SIL for all function bodies, @_transparent
functions can only reference internal functions that are declared
@_versioned, otherwise there's no serialized body and no public entry
point, so any client that inlines the @_transparent function will
not be able to link.
This patch adds the minimum set of @_versioned declarations to allow
a non-optimized build of the standard library and overlays.
Recall that this attribute is just a temporary hack to make progress
on building the standard library with resilience enabled.
Once availability and resilience learn about each other, @_versioned
will be replaced by having an availability annotation on an internal
declaration. Invariants will be diagnosed by Sema instead of asserting
in the SIL verifier.
Finally, the set of "internal but available" declarations will
eventually be audited instead of determined by experimentation.
This almost closes out https://bugs.swift.org/browse/SR-267.
The remaining issue is an interaction between SIL optimizations and
serialization that will be fixed with some upcoming changes to the
optimizer.
