The main change here is that we no longer forward ownership through
unchecked_bitwise_cast. The reason why is that unchecked_bitwise_cast creates a
new "reference count" identity to the optimizer. This is reflected in the SIL
ownership model by unchecked_bitwise_cast returning a value with unowned
ownership. We really do not want to traffic in such values, so we copy the value
after the cast to ensure that result is valid.
Found while updating SILGen tests for +0.
rdar://34222540
This method was not distinguishing in between in_guaranteed and in
parameters. This would cause the curry thunk where this is used to not copy
in_guaranteed parameters before passing in the parameter to the
partial_apply. This can not affect +1 code since the curry thunk will always
have self at +1.
I also refactored code in:
1. SILGenPoly.
2. SILGenProlog.
3. SILGenConstructor.
to use this function instead of their own reimplementations of the same thing.
This should be NFC for +1 code and is tested by test updates when +0 is enabled.
rdar://34222540
Previously SwitchEnumBuilder was in SILGenBuilder.{h,cpp} and
SwitchEnumCaseFullExpr was in its own file. This really made no sense since:
1. The two classes are inherently related to each other so really should be
together in the source base.
2. SwitchEnumBuilder uses a SILGenBuilder, but is really a separate independent
concept/entity, so there really is no reason to keep it in SILGenBuilder.cpp.
Just a quick fix to eliminate something that was bugging me.
NFC.
This would cause us to not properly create cleanups on tuples, causing potential
memory leaks. Luckily, I verified that we previously did not call this anywhere
in the compiler by removing the method in question from SILGenBuilder and
performing a successful build of swift. So we do not need to worry about this
bug on 4.1/5.0. I think I added it just for completeness since we had other such
ManagedValue methods.
Caught by the sil ownership verifier while running the argument shuffle test
with +0 rvalues and the commit merged with this commit.
rdar://34222540
This eliminates a case where we were not moving a cleanup onto a forwarding case
and instead just jammed the original cleanup and the new value into 1 managed
value.
NFC, but helps the ownership verifier.
rdar://34222540
I was thinking about this last night. I think the reason that this difference
came up is that people saw the SILGenBuilder SILValue based conformance APIs and
copied their calling of SILBuilder SILValue APIs. In the general case this is
not safe, since in some cases we need to add conformances.
Noticed by inspection.
This commit does two different things:
1. Changes some code paths in SILGenConvert to use SILGenBuilder APIs.
2. It eliminates a few bugs in this path exposed by running the SILGen tests
with +0 enabled.
The bug specifically is that we are assuming in this code that the input value
is always at +1, so we unconditionally forward the input value and then create
destroys on the output. This is not correct in general (since we have guaranteed
values) and occurs all the time with +0 arguments enabled.
This is tested by running the SILGen tests with +0 arguments enabled.
rdar://34222540
I don't think there's a way to test this right now because we don't
actually support SwiftValue and so on except under ObjCInterop, but
it's certainly more future-proof.
at AnyObject?.
Also, ensure that @convention(block) functions can be erased to
AnyObject, and teach SILGen how to do this with unchecked_ref_cast.
Fixes a source compatibility suite regression.
It additionally removes some code from SILGenBuilder::createUncheckedEnumData
that introduced extra borrows. That is really the builder's caller's
responsibility. Plus, it isn't that hard to do anymore now that one can just
call ManagedValue::borrow.
rdar://34222540
This takes a series of ManagedValues and combines them together into 1 tuple. It
assumes that all non-trivial ManagedValues are all at +1 or all at +0. It leaves
the verification to the ownership verifier since this would immediately trigger
the ownership verifier when the instruction is created by the SILBuilder.
rdar://34222540
The bridging function that we are calling here takes in the value to be bridged
at +0. We were storing that value via a normal store. This looks like a double
consume since we were destroying the value later. Now we use a store_borrow.
rdar://29791263
Except GenericEnvironment.h, because you can't meaningfully use a
GenericEnvironment without its signature. Lots less depends on
GenericSignature.h now. NFC
This replaces the '[volatile]' flag. Now, class_method and
super_method are only used for vtable dispatch.
The witness_method instruction is still overloaded for use
with both ObjC protocol requirements and Swift protocol
requirements; the next step is to make it only mean the
latter, also using objc_method for ObjC protocol calls.
Use the ManagedValue forms of the SILInstruction constructors
where possible. This ensures that after emitting an instruction
such as an upcast, we rewrite the value's cleanup to destroy
the new value, and not the old value. This is important because
the ownership verifier asserts that instructions dominated by
a destroy cannot use the destroyed value.
Should be NFC, since the ownership verifier is off by default
for now.
Remove the cast consumption kind from all unconditional casts. It
doesn't make sense for unconditional casts, complicates SIL ownership,
and wasn't fully supported for all variants. Copies should be
explicit.
These instructions have the same semantics as the *ExistentialAddr instructions
but operate directly on the existential value, not its address.
This is in preparation for adding ExistentialBoxValue instructions.
The previous name would cause impossible confusion with "opaque existentials"
and "opaque existential boxes".
Previously we were storing a pointer to the non-yet blockified function and not
cleaning it up. This was safe since we were performing a copy_block on the block
and destroying the SSA value of the non-yet blockified function. This looks like
a double consume to the ownership verifier. To fix this, I changed the bridging
code to use a new entrypoint for storing on SILGenBuilder that just does the
right thing by forwarding the cleanup on the SSA value and transfering it to the
address. This means the address will be destroyed instead of the SSA value,
yielding proper ownership.
rdar://31880847
When I originally implemented this, I did not understand why an unowned(unsafe)
value was unsafe. I thought it was unsafe since the value was not meant to be
paired with (which is why I used the unmanaged_retain_value). Instead it just
means that we perform an unconditional copy without checking if the unowned
value is actually live. In contrast, an unowned(safe) value, we use
copy_unowned_value which performs an assert that the unowned value is still
alive before copying.
From a non-semantic sil perspective, since I still was retaining the value
properly, there was not a bug by using the unmanaged_retain_value instruction.
rdar://31880847
The main thing here is that we create a cleanup that inserts the
end_borrow_argument. Once I merge end_borrow with end_borrow_argument, there
will only be one cleanup.
rdar://31880847
Use 'hasAssociatedValues' instead of computing and discarding the
interface type of an enum element decl. This change has specifically not
been made in conditions that use the presence or absence of the
interface type, only conditions that depend on the presence or absence
of associated values in the enum element decl.
Till now createApply, createTryApply, createPartialApply were taking some arguments like SubstCalleeType or ResultType. But these arguments are redundant and can be easily derived from other arguments of these functions. There is no need to put the burden of their computation on the clients of these APIs.
The removal of these redundant parameters simplifies the APIs and reduces the possibility of providing mismatched types by clients, which often happened in the past.
The new API is broken. Popping a generic context frees all
dependent type lowerings, so this function returns a pointer
to freed memory.
This reverts commit 24dfae0716.
This commit does a few things:
1. It uses SwitchEnumBuilder so we are not re-inventing any wheels.
2. Instead of hacking around not putting in a destroy for .None on the fail
pass, just *do the right thing* and recognize that we have a binary case enum
and in such a case, just emit code for the other case rather than use a default
case (meaning no cleanup on .none).
rdar://31145255
