The fix for methods to lower the dynamic method type from the substituted AST type of the expression also needed to be applied to the optional chaining, subscript, and property paths.
This also exposed a problem in the Clang importer, where imported subscript accessors would get the unbound generic context type as their Self parameter type instead of the type with the correct generic parameters. Fix this by renaming the all-too-convenient ParamDecl::createSelf factory to `createUnboundSelf`, and introduce a new `createSelf` that uses the bound generic type.
Fixes rdar://problem/26447758.
When we override a property to add a didSet, Sema also synthesizes
a getter that simply delegates to the superclass property getter.
The synthesized getter is marked @_transparent. This means that if
the superclass getter is also transparent, but less visible than
the override, mandatory inlining will crash with an assertion.
To fix this, make sure SILGen does not emit a direct reference to
a superclass method if the current function is marked [fragile]
but the method is not.
Fixes <rdar://problem/26408353>.
When an ObjC generic method is found by AnyObject dispatch, we don't have any type information to bind generic parameter dependencies. Sema expands these generic parameters to their upper bounds in an AnyObject dispatch. However, SILGen was still lowering the type of a dynamic method invocation from the method's formal type, expecting its generic parameters to be bound by substitutions provided from a call. Lower dynamic method calls using the substituted type from the AST instead to avoid this. Fixes rdar://problem/26380562.
We did this for func decls in script, so that DI can flag func decls that access script globals before they've been initialized, but we failed to do so for closures, causing us to miss DI violations when closures referenced script globals before their initialization. Fixes rdar://problem/24357063.
Fixes SR-613, a miscompile that caused an overrelease of "self" when partially applying a protocol method to a generic or existential of a refined class-constrained protocol.
We would potentially emit a closure multiple times when converting
a closure to a @convention(c) type. This would result in a compiler
crash if a stored property of @convention(c) type had an initializer
expression and the containing type declaration had multiple
initializers.
Fixes <rdar://problem/25632886>.
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.
Add yet one more flavor of hack to DI to recognize where we are
delegating the initialization of 'self'. The existing hack in this
area (for Objective-C factory initializers) is based on recognizing
the value_metatype instruction that feeds into the application of the
factory initializer. C functions imported as initializers don't have a
metatype argument, so instead tag the assignment into the self box as
the initialization of self.
As a minor cleanup in this area, don't emit the dead value_metatype
instruction when invoking a C-imported factory initializer.
Always statically dispatch to C functions imported as members, and
call to the foreign entry point. This gets us through SILGen, but DI
is still deeply unhappy with the resulting SIL.
We do clever tricks to avoid having to serialize the full type of a
partial_apply instruction, but those conflicted with our clever tricks
for handling unusual return conventions. Make sure we do all type
calculations for partial_apply in one place. (Credit to Slava for
both introducing the problem and immediately seeing how to fix it.)
This should allow re-application of e6a519f and 86dcce1.
Introduce abstraction patterns for curried C-functions-as-methods for type lowering, and plumb the "foreign self parameter index" through call emission so that we emit the "self" parameter in the right position. This gets us handling C functions imported as methods with explicit swift_name attributes in simple, fully-applied cases. There's still more work to be done for properties, partial applications, and initializers introduced by extensions.
Now that we apply the callback with the correct generic signature, the
assert can go away. It was being triggered if the protocol extension was
defined in a different resilience domain; otherwise we prefer direct
access anyway.
Note that materializeForSet now has to be able to re-abstract Self when
invoking the callback, since we might have to go from a thin metatype
to a thick metatype.
This is used when materializing an LValue to share state between
the read and write phases of the access, replacing the 'temporary'
and 'extraInfo' parameters that were previously being passed around.
It adds two new fields, origSelfType and genericSig, which will be
used in an upcoming patch to actually apply the callback with the
current generic signature.
This will finally allow us to make use of materializeForSet
implementations in protocol extensions, which is a prerequisite
for enabling resilient default implementations of property and
subscript requirements.
In IRGen, @autoreleased return values are always converted to +1 by
calling objc_retainAutoreleasedReturnValue(), so a partial application
thunk cannot have a result with @autoreleased convention. Just turn
it into @owned instead, since that's what it is, using similar logic
as the @unowned_inner_pointer => @unowned case.
Fixes <rdar://problem/24805609>.
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.
There's a group of methods in `DeclContext` with names that start with *is*,
such as `isClassOrClassExtensionContext()`. These names suggests a boolean
return value, while the methods actually return a type declaration. This
patch replaces the *is* prefix with *getAs* to better reflect their interface.
When the nearest implementation of a superclass's implementation of a
method is in the same module, eagerly emit a direct call to the method
instead of relying on the devirtualizer for these, since this is a very
lightweight check and can make -Onone builds faster.
And use project_box to get to the address value.
SILGen now generates a project_box for each alloc_box.
And IRGen re-uses the address value from the alloc_box if the operand of project_box is an alloc_box.
This lets the generated code be the same as before.
Other than that most changes of this (quite large) commit are straightforward.
This removes the -use-native-super-method flag and turns on dynamic
dispatch for native method invocations on super by default.
rdar://problem/22749732
- isTypeParameter() -- check if this is an archetype or dependent
interface type.
- requiresClass() -- check if this is a class-constrained type
parameter.
The old isOpaque() check has been replaced by
(isTypeParameter() && !requiresClass(moduleDecl)).
This allows us to pass the ModuleDecl on down to
GenericSignature::requiresClass(), enabling the use of
interface types in abstraction patterns.
NFC for now.
This eliminates some minor overheads, but mostly it eliminates
a lot of conceptual complexity due to the overhead basically
appearing outside of its context.
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.
When enabled, generate closure functions with guaranteed conventions as their context parameters, and pass context arguments to them as guaranteed when possible. (When forming a closure by partial_apply, the partial apply still needs to take ownership of the parameters, regardless of their convention.)
Instead of bodging a representation of the SIL capture parameters for a closure into the formal type of closure SILDeclRefs, introduce those parameters in a separate lowering step. This lets us clean up some TypeLowering code that was tolerating things like SILBoxTypes and naked LValueTypes in formal types for nefarious ends (though requires some hacks in SILGen to keep the representation of curry levels consistent, which is something I hope to clean up next). This also decouples the handling of captures from the handling of other parameters, which should enable us to make them +0. For now, there should be NFC.
