When we call the DeclContext variants of these, use the
DeclContext's GenericEnvironment instead of GenericParamList.
Also, these functions would take a resolver argument, but we
always passed in nullptr, so just remove it now.
The old GenericParamList-based versions are still there
since they're called directly from SIL. They will go away
once SILFunction::ContextGenericParams is replaced with
a GenericEnvironment.
Simplify e.g., ASTContext::getBridgedToObjC(), which no longer needs
the optional return.
Eliminate the now-unused constraint kind for checking bridging to
Objective-C.
Bitcast the AnyObject result to AnyObject?, then call our new helper function, so that we can handle nils without choking. Fixes rdar://problem/27874026.
This is still a pretty bad code-generation pattern, but the layering
stuff makes it challenging to do the right thing.
Also, bridge non-optional NSErrors to Error using init_existential_ref
instead of going through the runtime function.
rdar://27810321
If a `T?` is converted to `Any?` to pass to a `_Nullable id` interface in ObjC, avoid the intermediate conversion and bridge straight to AnyObject? too.
- 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.
Introduce bridging of NSError to ErrorProtocol, so an Objective-C API
expressed via an "NSError *" will be imported using ErrorProtocol in
the Swift. For example, the Objective-C method:
- (void)handleError:(NSError *)error userInteractionPermitted:(BOOL)userInteractionPermitted;
will now be imported as:
func handleError(_ error: ErrorProtocol, userInteractionPermitted: Bool)
This is bullet (3) under the proposed solution of SE-0112. Note that
we made one semantic change here: instead of removing the conformance
of NSError to ErrorProtocol, which caused numerous problems both
theoretical and actual because the model expects that an NSError
conforms to ErrorProtocol without requiring wrapping, we instead limit
the ErrorProtocol -> NSError conversion that would be implied by
bridging. This is defensible in the short term because it also
eliminates the implicit conversion, and aligns with SE-0072, which
eliminates implicit bridging conversions altogether.
Now that ObjC types can be generic, we need to satisfy the type system by plumbing pseudogeneric parameters through func-to-block invocation thunks. Fixes rdar://problem/26524763.
We were failing to bridge Array<T> parameters in the signatures of Objective-C generics when their NSArray<T> * type in ObjC depended on generic parameters. This partially fixes rdar://problem/26371959, though IRGen still needs a fix to get us all the way through (which @rjmccall is working on).
(@DougGregor did all the work here, I'm just testing and committing.)
Bridging thunks don't yet support bridging address-only types, but
ideally they should, so that we can bridge Objective-C types to
resilient value types.
This came up while I was adding @_fixed_layout declarations in
the standard library. To make this easier to figure out in the
future, add the asserts to the bridging logic for now.
Also, to avoid hitting the asserts when we emit a reference to a
C function with an incompatible type, don't emit the foreign
function at all until we determine that the ABI conversion is safe.
SILGen's bridging logic was recognizing the various bridged types
(String/Array/Dictionary/Set) using ad-hoc logic, then jumping into
the generic, _ObjectiveCBridgeable-based bridging logic. Replace the
ad-hoc logic with an _ObjectiveCBridgeable conformance query.
SILGen still has Array/Dictionary/Set-specific hacks for collection
up/downcasting, but the bridging code is now generic.
Migrate the check for whether a given type is representable in
Objective-C, which is currently used to verify when @objc can be
inferred or verify that an explicitly-written @objc is well-formed,
from Sema into a set of queries on the Type within the AST library, so
it can be used in other parts of the compiler.
As part of this refactoring, clean up and improve a number of aspects
of this code:
* Unify the "trivially representable" and "representable" code paths
into a single code path that covers these cases. Clarify the
different levels of "representable" we have in both the code and
in comments.
* Distinguish between representation in C vs. representation in
Objective-C. While we aren't using this now, I'm anticipating it
being useful to allow exporting C interfaces via @_cdecl (or
similar).
* Eliminate the special cases for bridging String/Array/Dictionary/Set
with their Foundation counterparts; we now consult
_ObjectiveCBridgeable conformances exclusively to get this
information.
* Cache foreign-representation information on the ASTContext in a
manner that will let us more easily get the right answer across
different contexts while providing more sharing than the TypeChecker
version.
Annoyingly, this only seemed to fix a small class of error where we
were permitting Unsafe(Mutable)Pointer<T> to be representable in
Objective-C when T was representable but not trivially representable,
e.g., T=String or T=AnyObject.Type.
Extend the use of
_ObjectiveCBridgeable._unconditionallyBridgeFromObjectiveC to all
bridged types rather than using the custom entry points. Note that
there is a lot of hackery around ensuring that the conformance is
correct, because Sema needs to anticipate that SILGen (or later SIL
passes) might need those conformances. This primarily affects the
overlays, but with generalized bridging that means any mixed
Objective-C/Swift framework with bridged types.
This reverts commit 052d2d0a69.
The only actual issue with the original change was a missing change to
the UIApplicationMain SILGen test, which needs to build SILGen
overlays to execute properly; -enable-source-import doesn't suffice.
Introduce a new entrypoint to _ObjectiveCBridgeable,
_unconditionallyBridgeFromObjectiveC, which handles unconditional
bridging from an optional Objective-C object (e.g., an NSString) to
its bridged Swift type. Use it in SILGen to perform NSString -> String
bridging rather than the custom entry point.
Another small step toward generalized bridging.
Also fixes a leak I introduced with the String -> NSString bridging;
we're always dealing with guaranteed +0, so borrow rather than forward
the "self" argument.
Provide a general mechanism for bridging from a Swift value type to
its corresponding Objective-C class type through the
_bridgeToObjectiveC witness of the appropriate _ObjectiveCBridgeable
protocol conformance. Only enable this new code for bridging String ->
NSString and work through the issues that crop up.
We cannot actually *delete* the _convertStringtoNSString entrypoint
yet, because there is some code that is depending on it indirectly;
I'll address that separately as part of the continued generalization
of the _ObjectiveCBridgeable mechanism.
Similarly to how we've always handled parameter types, we
now recursively expand tuples in result types and separately
determine a result convention for each result.
The most important code-generation change here is that
indirect results are now returned separately from each
other and from any direct results. It is generally far
better, when receiving an indirect result, to receive it
as an independent result; the caller is much more likely
to be able to directly receive the result in the address
they want to initialize, rather than having to receive it
in temporary memory and then copy parts of it into the
target.
The most important conceptual change here that clients and
producers of SIL must be aware of is the new distinction
between a SILFunctionType's *parameters* and its *argument
list*. The former is just the formal parameters, derived
purely from the parameter types of the original function;
indirect results are no longer in this list. The latter
includes the indirect result arguments; as always, all
the indirect results strictly precede the parameters.
Apply instructions and entry block arguments follow the
argument list, not the parameter list.
A relatively minor change is that there can now be multiple
direct results, each with its own result convention.
This is a minor change because I've chosen to leave
return instructions as taking a single operand and
apply instructions as producing a single result; when
the type describes multiple results, they are implicitly
bound up in a tuple. It might make sense to split these
up and allow e.g. return instructions to take a list
of operands; however, it's not clear what to do on the
caller side, and this would be a major change that can
be separated out from this already over-large patch.
Unsurprisingly, the most invasive changes here are in
SILGen; this requires substantial reworking of both call
emission and reabstraction. It also proved important
to switch several SILGen operations over to work with
RValue instead of ManagedValue, since otherwise they
would be forced to spuriously "implode" buffers.
The main idea here is that we really, really want to be
able to recover the protocol requirement of a conformance
reference even if it's abstract due to the conforming type
being abstract (e.g. an archetype). I've made the conversion
from ProtocolConformance* explicit to discourage casual
contamination of the Ref with a null value.
As part of this change, always make conformance arrays in
Substitutions fully parallel to the requirements, as opposed
to occasionally being empty when the conformances are abstract.
As another part of this, I've tried to proactively fix
prospective bugs with partially-concrete conformances, which I
believe can happen with concretely-bound archetypes.
In addition to just giving us stronger invariants, this is
progress towards the removal of the archetype from Substitution.
