This expression node is only used when applying the results of
expression type checking. It initially appears above the function
reference that returns an optional that needs to be unwrapped, and
then when dealing with function application we remove this and insert
a node to force-unwrap the result of the function application.
Use the LValue formal evaluation scope to destroy temporary lvalues that aren't
part of the expression's resulting value.
Disable an old hack that destroyed call site arguments after the call.
This is the first step in cleanup up LValue materialization.
Sometimes we need to copy/borrow now.
*NOTE* right now it is basically impossible to test this using a fake stdlib
since I would need to implement Array or String in my local stdlib since this
comes up via ArrayToPointer/friends. If/when we flip the switch though, this is
guaranteed to be tested by stdlib dependent tests that we already have in tree.
rdar://34222540
Before this change, stepping through the code
1 foo(x,
2 f(a)
3 f(b)
4 )
would visit the code in the order 2, 3, 4, with the function call
being on line 4. After this patch the order is 2, 3, 1 with the
function call being on line 1. This is both closer to what clang
generates for simialar C code and more useful to the programmer since
it is easier to understand which function is being called in a nested
expression.
rdar://problem/35430708
Now that we emit the callee at the right time, we no longer need
to force emit the 'self' argument source at +0 and possibly
convert it to +1 later.
This is NFC, except it means we end_borrow the self value a bit
sooner sometimes, which is a good thing.
We need to borrow guaranteed values with sil ownership and need to
distinguish between @callee_guaranteed and other context conventions in
a few places.
SR-5441
rdar://33255593
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.
This eliminates a bunch of complexity from delegating init self since now we
have a clear bifurcation, before the begin of the super.init call, you use the
normal cleanup machinery, but once you have begun the super.init call, you use
the lvalue/formal evaluation machinery.
rdar://31521023
It is only safe to perform a destroy_value on an alloc_box that contains an
initialized value. We preserve the original cleanups for the value we are
pushing through the scope implying that the box will not contain an initialized
value when its lifetime ends (just like an alloc_stack). Thus we must use
dealloc_box here.
The surprising thing about tracking down this error is that I was not hitting
any memory issues at -Onone. Instead what was happening was that at -O, we were
miscompiling (creating non-dominating uses of SSA values) in the face of an
address being taken twice.
This does not seem to hit any SILGen tests today (I hit this when testing a
patch I am trying to land today).
rdar://31521023
This comes down to popping the formal evaluation scope and then performing a
popPreservingValue through the resulting normal Scope.
As a cleanup, I changed ArgumentScope.popPreservingValue(ManagedValue) to just
Scope::popPreservingValue instead of reimplementing said functionality.
rdar://31521023
This is in prepatation for splitting getAtUncurryLevel into one function that
returns the CalleeTypeInfo (which is needed early) and a later one that returns
a ManagedValue, which can occur later.
rdar://33358110
This is done by introducing a new result parameter called
FirstLevelApplicationResult. This communicates that the given parameters are not
inout parameters, but rather just result parameters.
As a result of this, many of the apply* methods only take the uncurry level and
the SILGenFunction context.
rdar://33358110
