closure lifetimes.
SILGen will now unconditionally emit
%cvt = convert_escape_to_noescape [guaranteed] %op
instructions. The mandatory ClosureLifetimeFixup pass ensures that %op's
lifetime spans %cvt's uses.
The code in DefiniteInitialization that handled a subset of cases is
removed.
To mark when a user of it is known to escape the value. This happens
with materializeForSet arguments which are captured and used in the
write-back. This means we need to keep the context alive until after
the write-back.
Follow-up patches to fully replace the PostponedCleanup hack in SILGen
by a mandatory SIL transformation pass to guarantee the proper lifetime
will use this flag to be more conservative when extending the lifetime.
The problem:
%pa = partial_apply %f(%some_context)
%cvt = convert_escape_to_noescape [not_guaranteed] [escaped] %pa
%ptr = %materialize_for_set(..., %cvt)
... write_back
... // <-- %pa needs to be alive until after write_back
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 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
This is a refactor that we want in general and allows me to use
ensurePlusOne(...) to ensure we retain all values we put into the partial
apply.
rdar://34222540
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.
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
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
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
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
This partially reverts commit 41f425a503.
The key thing is that now it is behind the semantic sil flag. I have an
additional patch that turns this back on in front of the flag, but it requires a
little bit of mandatory pass work that Erik is going to hit this week.
rdar://31145255
The reason that this is being done is that:
1. SILGenFunction is passed around all throughout SILGen, including in between
APIs some of which call the SILGenFunction variable SGF and others that call it
gen.
2. Thus when one is debugging code in SILGen, one wastes time figuring out what
the variable name of SILGenFunction is in the current frame.
I did not do this by hand. I did this by:
1. Grepping for "SILGenFunction &gen".
2. By hand inspecting that the match was truly a SILGenFunction &gen site.
3. If so, use libclang tooling to rename the variable to SGF.
So I did not update any use sites.
