We don't really need to mangle the AST type of the callback, besides
it doesn't have an AST type at all, because it is polymorphic.
Also, mangle the closure as if it were parented by the requirement
and not the witness, for consistency with witness thunks.
The mangling should still be unique since it includes the conformance.
NFC other than updating tests for new mangling.
I'm planning on changing materializeForSet to return the callback
as a RawPointer, and casting it to the correct polymorphic SILFunctionType
type at the call site.
This will allow us to call it with the right generic signature, which
is currently not possible since it is returned as an optional of an
AST function type, and optionals of SIL function types are not permitted.
Previously we would emit two types of MaterializeForSet implementations
in SILGen:
- materializeForSet for a concrete storage declaration
- materializeForSet witness thunk in a conformance
This refactoring decouples the code from taking a conformance, which is
needed for two new types of materializeForSet that we need:
- materializeForSet witness thunk in a default witness table -- this is
necessary in order to be able to resiliently add storage requirements
with default implementations to protocols
- materializeForSet vtable thunk -- this is necessary to fix a missing
re-abstraction case with overriding storage in a subclass
This patch brings us closer to implementing these two. For default
implementations, we still have an issue in that the materializeForSet
has a different "generic signature abstraction pattern" in concrete
and default witnesses, so default and concrete witnesses for
materializeForSet are currently ABI-incompatible because the type
metadata for the storage is passed differently to the callback.
When we emit calls to getters and setters with emitApply(), the call
emission code ends up re-abstracting the result of a getter or the
parameter to a setter.
As a result, getOrigFormalType() was incorrect for logical path
components. This was worked around by only adding an OrigToSubst
path component to an lvalue if the last path component was physical.
This caused a problem in the following case:
1) There was an abstraction difference between the storage of the
protocol requirement and the storage of the protocol witness
2) There was an abstraction difference between the storage of the
protocol witness, and the fully-substituted type of the witness
An example is when the witness is in a protocol extension, and uses
'Self' or some other associated type which is concrete and loadable
in the conformance.
Fix this properly by splitting up getStorageTypeData() into two
functions, one used when adding physical path components and another
one used for logical.
As a result, we can now give the correct abstraction pattern to
logical path components.
This ireapplies commit 255c52de9f.
Original commit message:
Serialize debug scope and location info in the SIL assembler language.
At the moment it is only possible to test the effects that SIL
optimization passes have on debug information by observing the
effects of a full .swift -> LLVM IR compilation. This change enable us
to write targeted testcases for single SIL optimization passes.
The new syntax is as follows:
sil-scope-ref ::= 'scope' [0-9]+
sil-scope ::= 'sil_scope' [0-9]+ '{'
sil-loc
'parent' scope-parent
('inlined_at' sil-scope-ref )?
'}'
scope-parent ::= sil-function-name ':' sil-type
scope-parent ::= sil-scope-ref
sil-loc ::= 'loc' string-literal ':' [0-9]+ ':' [0-9]+
Each instruction may have a debug location and a SIL scope reference
at the end. Debug locations consist of a filename, a line number, and
a column number. If the debug location is omitted, it defaults to the
location in the SIL source file. SIL scopes describe the position
inside the lexical scope structure that the Swift expression a SIL
instruction was generated from had originally. SIL scopes also hold
inlining information.
<rdar://problem/22706994>
At the moment it is only possible to test the effects that SIL
optimization passes have on debug information by observing the
effects of a full .swift -> LLVM IR compilation. This change enable us
to write targeted testcases for single SIL optimization passes.
The new syntax is as follows:
sil-scope-ref ::= 'scope' [0-9]+
sil-scope ::= 'sil_scope' [0-9]+ '{'
sil-loc
'parent' scope-parent
('inlined_at' sil-scope-ref )?
'}'
scope-parent ::= sil-function-name ':' sil-type
scope-parent ::= sil-scope-ref
sil-loc ::= 'loc' string-literal ':' [0-9]+ ':' [0-9]+
Each instruction may have a debug location and a SIL scope reference
at the end. Debug locations consist of a filename, a line number, and
a column number. If the debug location is omitted, it defaults to the
location in the SIL source file. SIL scopes describe the position
inside the lexical scope structure that the Swift expression a SIL
instruction was generated from had originally. SIL scopes also hold
inlining information.
<rdar://problem/22706994>
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.
The following patch introduced a regression where materializeForSet
did not invoke didSet/willSet for stored properties with observers:
<249242b08d>
The old SILGen materializeForSet was only used for witness thunks,
where it used Ordinary access semantics for the storage.
When I switched over to using the new materializeForSet implementation
for static thunks too, I added some logic to use DirectToStorage access
semantics where appropriate, however this was wrong for observable
properties, which need DirectToAccessor semantics.
Fixes <rdar://problem/24315392>.
We always passed nullptr to getMaterializeForSetCallbackType(), so
I'm assuming it is safe to just delete this bit of dead code.
Now the only remaining usages of PolymorphicFunctionType in SIL are
assertions ensuring that PolymorphicFunctionType doesn't end up there.
There are still a number of usages of AllArchetypes though, via
SILFunction::ContextGenericParams. Once @rjmccall finishes the
heavy lifting on the IRGen side, it should be pretty easy to rip
these out from SIL, too.
The original implementation of SILGenMaterializeForSet.cpp did not
support the case where SelfInterfaceType contained a generic
parameter. Recent changes to switch SILGen to always open-code
materializeForSet, and Sema to always emit accessors, exposed this
in validation-tests.
This improves MaterializeForSetEmitter to support emission
of static materializeForSet thunks, as well as witnesses.
This is now done by passing in a nullptr as the conformance
and requirement parameters, and adding some conditional code.
Along the way, I fixed a few limitations of the old code,
namely weak/unowned and static stored properties weren't
completely plumbed through. There was also a memory leak in
addressed materializeForSet, the valueBuffer was never freed.
Finally, remove the materializeForSet synthesis in Sema since
it is no longer needed, which fixes at least one known crash
case.
In order to fix some other issues that came up with materializeForSet
and resilience, I had to bite the bullet and finish off John's code
for open-coding materializeForSet emission in SILGen. This patch
makes the subsequent changes easier to review.
