To be able to constant fold string interpolation, the right semantic attributes must be in place.
Also, the interpolation's write function must be inlinable.
For the _typeName constant folding, a semantic attribute is required.
If a key path literal appears in a generic context with an existing context descriptor, this will allow us to
save some code size by not having to emit a separate GenericEnvironment descriptor.
This can be used by compiler-generated code as a size optimization for metadata access, using a
mangled name instead of possibly many open-coded metadata calls. It can also allow reflection
libraries outside of the standard library to turn type reference strings into in-process metadata
pointers in a robust way. rdar://problem/46451849
Always use mangled type names to represent type metadata in keypath patterns.
For generic types, use the generic environment to pull substituted types
from the instantiation arguments.
Finishes the type metadata part of rdar://problem/38038799.
Simplify the signature of the internal _getTypeByMangledName() used by the
standard library to what we actually (currently) use. Drop it as a
compatibility override, because it’s not a useful place to introduce
customization.
Refactor and rename _StringGutsSlice, apply NFC-aware fast paths to a
new buffered iterator.
Also, fix bug in _typeName which used to assume ASCIIness and better
SIL optimizations on StringObject.
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.
Extend _typeByMangledName with support for user-provided type parameter
substitutions, where type parameters that occur in the mangling can be
replaced with specific types.
_getTypeByMangledName() is more general and will be the way forward. Use
that instead. Note that we're still keeping around Foundation-only SPI
function _typeByName() in the Swift standard library, until we settle
on what the standard library API should be like for this functionality.
Introduce a standard library/runtime entry point that produces type metadata
given a mangled name, based on the TypeDecoder logic lifted from the remote
mirrors library.
Implement support for tuple types as a proof-of-concept.
The old method of constructing a mangled class name does not work anymore with the new mangling scheme.
Also, by using the re-mangler, _typeByName now works with class names containing non-ascii characters.
As proposed in SE-0107: UnsafeRawPointer:
Rename 'init(allocatingCapacity:)' to 'UnsafeMutablePointer.allocate(capacity:)'
Rename 'deallocateCapacity' to 'deallocate(capacity:)'
`allocate` should not be an initializer. It's primary function is to allocate
memory, not initialize a pointer.
Remove the reference to String, which leaks internal implementation details,
check for invalid inputs, and make the API more flexible. Remove the similar
Swift API, since it provides no additional value.
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.
