Previously, the stdlib provided:
- getters for AnyKeyPath and PartialKeyPath, which have remained;
- a getter for KeyPath, which still exists alongside a new read
coroutine; and
- a pair of owned mutable addressors that provided modify-like behavior
for WritableKeyPath and ReferenceWritableKeyPath, which have been
replaced with modify coroutines and augmented with dedicated setters.
SILGen then uses the most efficient accessor available for the access
it's been asked to do: for example, if it's been asked to produce a
borrowed r-value, it uses the read accessor.
Providing a broad spectrum of accessor functions here seems acceptable
because the code-size hit is fixed-size: we don't need to generate
extra code per storage declaration to support more alternatives for
key paths.
Note that this is just the compiler ABI; the implementation is still
basically what it was. That means the implementation of the setters
and the read accessor is pretty far from optimal. But we can improve
the implementation later; we can't improve the ABI.
The coroutine accessors have to be implemented in C++ and used via
hand-rolled declarations in SILGen because it's not currently possible
to declare independent coroutine accessors in Swift.
At the moment the location being reported is inside the standard
library, which is not very helpful. Instead, the location should point
at the `try!` expression in the application code.
Fixes: rdar://problem/21407683
Builds on 36eae9d4f6 to emit a message instead of just trapping
when a switch over a non-frozen enum ends up not matching anything.
If the enum is known to be an @objc enum, the message is
unexpected enum case 'MyEnum(rawValue: -42)'
and if it's anything else (a Swift enum, a tuple containing enums,
whatever), it's a more opaque
unexpected enum case while switching on value of type 'MyEnum'
The reason for this is to avoid calling String(describing:) or
String(reflecting:) an arbitrary value when the enum might conform to
CustomStringConvertible and therefore /itself/ have a switch that's
going to fall off the end. By handling plain @objc enums (using a
bitcast), we've at least covered the 90% case.
rdar://problem/37728359
* [runtime] Clean up symbols in error machinery.
* [runtime] Clean up symbols in Foundation overlay.
* [runtime] Clean up symbols in collections and hashing.
* [runtime] Remove symbol controls from the Linux definition of swift_allocError.
* [tests] Add more stub functions for tests that link directly to the runtime.
Add a SILLocation-based syntactic suppression for diagnostics of static
access conflicts on the arguments to the Standard Library's swap() free
function. We'll suppress for calls to this function until we have a safe
replacement.
- Most immediately, we now have `withoutActuallyEscaping` as a supported way to temporarily reference a nonescaping closure as if it were escapable, and we plan to break the ABI for escaping and nonescaping closures so that the old `unsafeBitCast` workaround no longer works.
- `unsafeBitCast` is also commonly used to kludge pointers into different types, but we have more semantically meaningful APIs for type punning now. Guide users towards those APIs.
- Suggest more specific and type-safe operations, like `bitPattern:` initializers or `unsafeDowncast`, for the situations where `unsafeBitCast` is being used to avoid dynamic type checks or reinterpret numerical bits.
This eliminates a pile of now-dead code in:
* The type checker, where we no longer have special cases for bridging conversions
* The expression ASTs, where we no longer need to distinguish bridging collection up/down casts
* SILGen, which no longer uses
Still to come is the removal of the
_(set|dictionary)Bridge(From|To)ObjectiveC(Conditional)? entrypoints
from the standard library. They're still used by some tests.
Bitcast the AnyObject result to AnyObject?, then call our new helper function, so that we can handle nils without choking. Fixes rdar://problem/27874026.
When emitting an existential erasure to Error from an archetype, use
the _getEmbeddedNSError() witness. If it produces an NSError, erase
that; otherwise, go through the normal erasure path.
Of course, make NSError and CFError implement _getEmbeddedNSError() so
this kicks in for the obvious cases as well as the more obscure ones.
Fixes the rest of SR-1562 / rdar://problem/26370984.
- Previously we didn't know how to bridge address-only types. Add some
plumbing for this. Not fully general yet, but with a bit more work we
could allow resilient value types to adopt _ObjectiveCBridgable, too.
For now, this is just intended to support the id-as-Any work.
- Specifically when going from a type without any other known bridging
strategy, emit a call to the new `_bridgeAnythingToObjectiveC` entry
point from the previous commit.
We may want to use optimized ErrorType representations that don't naturally "become" NSErrors, such as tagged-pointer representations of small error enums, or a tagged function pointer to a deferred error type constructor. Rename the runtime function to something a bit more descriptive of its real purpose, not its implementation.
Swift SVN r27209
We define two new library functions _knownForceBridgeFromObjectiveC/_knownConditionallyBridgeFromObjectiveC, similar to _forceBridgeFromObjectiveC/_conditionallyBridgeFromObjectiveC. The main difference is that they require their arguments to conform to _BridgedToObjectiveC and _BridgedToObjectiveC. _ObjectiveCType accordingly. With this change, it is now possible to invoke the _BridgedToObjectiveC._forceBridgeFromObjectiveC witness directly, without going via the inefficient swift_bridgeNonVerbatimFromObjectiveC.
So now, for a cast O -> S, if it can be statically proven that an ObjC type O is bridgeable to a Swift type S implementing the _BridgedToObjectiveC protocol (i.e. O is the class (or its subclass) defined by the S._ObjectiveCType alias), we can generate a code to invoke the newly defined library function _knownForceBridgeFromObjectiveC/_knownConditionallyBridgeFromObjectiveC instead of _forceBridgeFromObjectiveC/_conditionallyBridgeFromObjectiveC.
After inlining, this will end-up invoking S._forceBridgeFromObjectiveC directly instead of invoking a more general, but less effective swift_bridgeNonVerbatimFromObjectiveC, which always performs conformance checks at runtime, even if conformances are known statically. As a result, no conformance checks are performed at run-time if conformances are known statically.
The client code making use of these new APIs and the tests are coming in the subsequent commits.
The naming of the two new helper library functions was discussed with Dmitri.
This is part of the bridging casts optimization effort. And it is specifically useful for e.g. rdar://19081345.
Swift SVN r27100
The problem here was that the _preconditionImplicitlyUnwrappedOptionalHasValue
compiler intrinsic was taking the optional/IUO argument as inout as a performance
optimization, but DI would reject it (in narrow cases, in inits) because the inout
argument looks like a mutation.
We could rework this to take it as an @in argument or something, but it is better
to just define this problem away: the precondition doesn't actually care about the
optional, it is just testing its presence, which SILGen does all the time. Have
SILGen open code the switch_enum and just have the stdlib provide a simpler
_diagnoseUnexpectedNilOptional() to produce the error message.
This avoids the problem completely and produces slightly better -O0 codegen.
Swift SVN r25254
Eliminate the intermediate top_level_code function. Now that SIL is expressive enough to express a "main" function, there's no reason for it, and this eliminates a bunch of mystery code in IRGen to thunk from main to top_level_code by reaching for hardcoded symbol names. Demystify the special code for setting up C_ARGC and C_ARGV by having SILGen look for a transparent "_didEnterMain" hook in the stdlib and emit a call to it.
Swift SVN r22525
This avoids a pointless copy every time an array literal is written, and will let us retire the horrible "alloc_array" instruction and globs of broken IRGen code. Implements rdar://problem/16386862, and probably fixes a bunch of bugs related to alloc_array brokenness.
Swift SVN r22289
This is essentially NFC, but the protocols we were calling into are
changing in a way that makes it hard to use the witnesses directly
from the type checker.
Swift SVN r20933
This means that we'll get deferred checking of array and dictionary
downcasts when writing "arr as Derived[]",
"(dict as? Dictionary<DerivedKey, DerivedValue>)!", etc, when the
collection can do so.
This is both a general optimization and also staging for
<rdar://problem/17319154>.
Swift SVN r18975
