This means that it can only have a guaranteed object as an operandand that we
validate that all uses of the result address of open_existential_box occur only
within the lifetime of said object's borrow scope.
(BaseT, @inout @unowned(unsafe) T) -> @guaranteed T
The reason for the weird signature is that currently the Builtin infrastructure
does not handle results well. Also, note that we are not actually performing a
call here. We are SILGening directly so we can create a guaranteed result.
The intended semantics is that one passes in a base value that guarantees the
lifetime of the unowned(unsafe) value. The builtin then:
1. Borrows the base.
2. Loads the trivial unowned (unsafe), converts that value to a guaranteed ref
after unsafely unwrapping the optional.
3. Uses mark dependence to tie the lifetimes of the guaranteed base to the
guaranteed ref.
I also updated my small UnsafeValue.swift test to make sure we get the codegen
we expect.
For those who are unaware, a transformation terminator is a terminator like
switch_enum/checked_cast_br that always dominate their successor blocks. Since
they dominate their successor blocks by design and transform their input into
the args form, we can validate that they obey guaranteed ownership semantics
just like a forwarding instruction.
Beyond removing unnecessary code bloat, this also makes it significantly more
easier to optimize/work with transformation terminators when converting @owned
-> @guaranteed since we do not need to find end_borrow points when the owned
value is consumed.
<rdar://problem/59097063>
SIL type lowering erases DynamicSelfType, so we generate
incorrect code when casting to DynamicSelfType. Fixing this
requires a fair amount of plumbing, but most of the
changes are mechanical.
Note that the textual SIL syntax for casts has changed
slightly; the target type is now a formal type without a '$',
not a SIL type.
Also, the unconditional_checked_cast_value and
checked_cast_value_br instructions now take the _source_
formal type as well, just like the *_addr forms they are
intended to replace.
This will ensure that the optimizer never eliminates the strong_retain. This
operation is meant to be unmanaged, we should respect the user's choice here
even in optimized builds.
This prevents ManagedValue APIs on SILGenBuilder from by mistake accesing
non-conformance tracking APIs on SILBuilder.
NOTE: Eventually, we should make SILGenBuilder compose with SILGenSILBuilder and
then rename SILGenBuilder to ManagedValueBuilder. I did not do that in this PR
since it becomes very disruptive since there is still a lot of code in SILGen
that uses SILValue APIs and I have not found a concise way to write such
code. But this patch at least defines away this error which has bitten us
before.
The problem here is that we were taking advantage of swift not-trashing the
original memory location after performing a load [take] to use load [take] as a
+0 load. This breaks the ownership verifier since the load [take] is never
actually destroyed. Instead this commit changes this code to use a load_borrow.
I found this when trying to enable ownership verification on
test/SILGen/indirect_enum.swift using some out of tree work that should have
fixed all of the ownership issues with SILGenPattern. Turns out I can just
enable ownership verification with just this change... so I did that as well in
this PR.
rdar://29791263
ConvertFunction and reabstraction thunks need this attribute. Otherwise,
there is no way to identify that withoutActuallyEscaping was used
to explicitly perform a conversion.
The destination of a [without_actually_escaping] conversion always has
an escaping function type. The source may have either an escaping or
@noescape function type. The conversion itself may be a nop, and there
is nothing distinctive about it. The thing that is special about these
conversions is that the source function type may have unboxed
captures. i.e. they have @inout_aliasable parameters. Exclusivity
requires that the compiler enforce a SIL data flow invariant that
nonescaping closures with unboxed captures can never be stored or
passed as an @escaping function argument. Adding this attribute allows
the compiler to enforce the invariant in general with an escape hatch
for withoutActuallyEscaping.
For now, the accessors have been underscored as `_read` and `_modify`.
I'll prepare an evolution proposal for this feature which should allow
us to remove the underscores or, y'know, rename them to `purple` and
`lettuce`.
`_read` accessors do not make any effort yet to avoid copying the
value being yielded. I'll work on it in follow-up patches.
Opaque accesses to properties and subscripts defined with `_modify`
accessors will use an inefficient `materializeForSet` pattern that
materializes the value to a temporary instead of accessing it in-place.
That will be fixed by migrating to `modify` over `materializeForSet`,
which is next up after the `read` optimizations.
SIL ownership verification doesn't pass yet for the test cases here
because of a general fault in SILGen where borrows can outlive their
borrowed value due to being cleaned up on the general cleanup stack
when the borrowed value is cleaned up on the formal-access stack.
Michael, Andy, and I discussed various ways to fix this, but it seems
clear to me that it's not in any way specific to coroutine accesses.
rdar://35399664
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.
