new API called ManagedValue::unmanagedBorrow() for places where we were really trying to model
an exclusive borrow.
ManagedValue::unmanagedBorrow() is just the old implementation.
rdar://29791263
I am using this for implementing tight scopes around specific call sites. The
way that it works is that the class performs the copy and asserts if one has not
called the cleanup method before end of scope has occured.
rdar://29791263
Everything here should be NFC after the ownership model eliminator except for 1
change where translation of unowned parameters is made more
correct. Specifically:
1. In manageParam, we make it so that if we allow PlusZero, we begin an actual
begin_borrow, end_borrow sequence. We can do this unconditionally since if the
passed in SILValue is already borrowed, we just return early.
2. In TranslateArguments::translateSingle(), we used to handle owned, unowned,
and guaranteed parameters all the same way. This is of course incorrect. Now we
do the following:
a. If our final translated value is guaranteed, but we want an unowned or
owned parameter, then we perform a copyUnmanaged().
b. If our final translated value is unowned and our argument must be a
guaranteed value, then we first transition the unowned value to an owned value
using SILGen::emitManagedRetain() and then transition from owned to guaranteed
using a emitBeginBorrow().
c. If our final translated value is owned and our argument must be a
guaranteed value, then we perform an emitBeginBorrow().
3. In forwardFunctionArguments(), if our argument requires a guaranteed
argument, we begin a begin borrow sequence.
rdar://29791263
This new API creates a new PHI argument in the current insertion block of the
SILBuilder with @owned ownership, creates a new ManagedValue with cleanup and
returns that ManagedValue. This eliminates one case where often times in SILGen
people use SILBuilder APIs on SILGenBuilder and then manage their own ownership
instead of gliding lightly on top of pure ManagedValue APIs.
rdar://29791263
This lets you do isa<AllocRefInst> to determine if the underlying ManagedValue
contains within it an AllocRefInst without needing to call getValue(). I would
like to restrict the number of places where getValue() needs to be called as
much as possible.
First, add some new utility methods to create SubstitutionMaps:
- GenericSignature::getSubstitutionMap() -- provides a new
way to directly build a SubstitutionMap. It takes a
TypeSubstitutionFn and LookupConformanceFn. This is
equivalent to first calling getSubstitutions() with the two
functions to create an ArrayRef<Substitution>, followed by
the old form of getSubstitutionMap() on the result.
- TypeBase::getContextSubstitutionMap() -- replacement for
getContextSubstitutions(), returning a SubstitutionMap.
- TypeBase::getMemberSubstitutionMap() -- replacement for
getMemberSubstitutions(), returning a SubstitutionMap.
With these in place, almost all existing uses of subst() taking
a ModuleDecl can now use the new form taking a SubstitutionMap
instead. The few remaining cases are explicitly written to use a
TypeSubstitutionFn and LookupConformanceFn.
When lowering closures, we avoid capturing the enclosing generic context when possible. However, the generic context may still be necessary to canonicalize types mentioned inside the closure, such as when an associated type is referred to that is same-typed to a concrete type. Fixes rdar://problem/30254048.
In cases where a default value is used for a parameter with generic
type, the argument list might be empty. In that case, we don't need
to emit any arguments!
Storing this separately is unnecessary since we already
serialize the enum element's interface type. Also, this
eliminates one of the few remaining cases where we serialize
archetypes during AST serialization.
[NFC] Add -enable-sil-opaque-values frontend option.
This will be used to change the SIL-level calling convention for opaque values,
such as generics and resilient structs, to pass-by-value. Under this flag,
opaque values have SSA lifetimes, managed by copy_value and destroy_value.
This will make it easier to optimize copies and verify ownership.
* [SILGen] type lowering support for opaque values.
Add OpaqueValueTypeLowering.
Under EnableSILOpaqueValues, lower address-only types as opaque values.
* [SIL] Fix ValueOwnershipKind to support opaque SIL values.
* Test case: SILGen opaque value support for Parameter/ResultConvention.
* [SILGen] opaque value support for function arguments.
* Future Test case: SILGen opaque value specialDest arguments.
* Future Test case: SILGen opaque values: emitOpenExistential.
* Test case: SIL parsing support for EnableSILOpaqueValues.
* SILGen opaque values: prepareArchetypeCallee.
* [SIL Verify] allow copy_value for EnableSILOpaqueValues.
* Test cast: SIL serializer support for opaque values.
* Add a static_assert for ParameterConvention layout.
* Test case: Mandatory SILOpt support for EnableSILOpaqueValues.
* Test case: SILOpt support for EnableSILOpaqueValues.
* SILGen opaque values: TypeLowering emitCopyValue.
* SILBuilder createLoad. Allow loading opaque values.
* SIL Verifier. Allow loading and storing opaque values.
* SILGen emitSemanticStore support for opaque values.
* Test case for SILGen emitSemanticStore.
* Test case for SIL mandatory support for inout assignment.
* Fix SILGen opaque values test case after rebasing.
We neglected to do this, so we would fail to emit protocol conformances synthesized from imported ObjC declarations in cases where that was the only apparent use of the conformance, such as SR-3739 and rdar://problem/30195308.
This fixes an issue where a same-type constraint making an
associated type into a tuple would lead to a crash, because
of confusion about whether it should be passed as a single
value or an exploded tuple.
Fixes <rdar://problem/30199401>.
In all cases except where phi arguments are concerned, we suppress the usage of
additional begin_borrow, end_borrow.
This just makes the SIL look a bit cleaner. There is no semantic difference.
rdar://29791263
These APIs were incorrectly using SILType.getSwiftRValueType() and calling
getTypeLowering. This is the correct way to get the typelowering of an already
lowered type that is used on a SILValue inside of a function.
Formal types are defined by the language's type system. SIL types are
lowered. They are no longer part of that type system.
The important distinction here is between the SIL storage type and the SIL value
type. To make this distinction clear, I refer to the SILFunctionTypes "formal"
conventions. These conventions dictate the SIL storage type but *not* the SIL
value type. I call them "formal" conventions because they are an immutable
characteristic of the function's type and made explicit via qualifiers on the
function type's parameters and results. This is in contrast to to SIL
conventions which depend on the SIL stage, and in the short term whether the
opaque values flag is enabled.
Separate formal lowered types from SIL types.
The SIL type of an argument will depend on the SIL module's conventions.
The module conventions are determined by the SIL stage and LangOpts.
Almost NFC, but specialized manglings are broken incidentally as a result of
fixes to the way passes handle book-keeping of aruments. The mangler is fixed in
the subsequent commit.
Otherwise, NFC is intended, but quite possible do to rewriting the logic in many
places.
Now that optional payloads can be re-abstracted, there's a case
where we need to do a tuple-to-tuple conversion on a direct result;
if the result is wrapped in an Optional. So I believe this assert
is not right.
Fixes <https://bugs.swift.org/browse/SR-3706>.
In Swift 3, we had a bug where you could provide argument labels
to a function call taking a single Any parameter, even if the
parameter did not have a label.
This mostly worked (with asserts off!) but in fact it would crash
in SILGen if you were calling an enum case constructor.
Since this 'feature' has been promoted from 'works on accident' to
'still a hack but guarded by Swift 3 mode and exists on purpose',
fix the crash, even though Swift 3 could not compile the code in
question.
Also add a Swift 3 mode check to the earlier SILGen hack, so that
when/if we remove Swift 3 mode it will be obvious that this code is
now dead too.
I realized over the weekend the follie of storing a borrowed cleanup on
ManagedValues themselves. The reasons for this are:
1. We assume all over SILGen that ManagedValue::hasCleanup() => Owned. I would
have to fix all of those parts of the compiler.
2. The reason for having a cleanup handle on ManagedValue is to be able to
forward owned arguments, so there is really no purpose since we never want to be
able to forward these arguments.
We already always associate a SILGenBuilder with one function, just like
SILBuilder, so there really is no reason not to store the SILGenFunction. The
reason why I want to do so here though is that I want access to the ManagedValue
APIs on SILGenFunction so I can begin to add Ownership endowed entry points on
SILBuilder that traffic only in ManagedValue instead of SILValue.
rdar://29791263
In SIL, the distinction between IUO and Optional is now lowered away, so there's no reason to emit any SIL at all when an IUO is converted to Optional formally in the AST. (Eventually this distinction ought to go away at the type system level too…) Memory promotion didn't understand initializations through unchecked_*_casts and would incorrectly flag them as improper captures, causing rdar://problem/26899492.
This is the first step towards eliminating:
* ManagedValue::forUnmanaged(SILValue)
* ManagedValue::ManagedValue(SILValue, CleanupHandle).
The reason why these two methods must be eliminated is that:
1. Currently non-trivial values are "borrowed" using
ManagedValue::forUnmanaged. With Semantic SIL, we are now able to represent
borrows via begin_borrow and end_borrow. This will make the semantics that
SILGen is trying to describe more accurate.
2. ManagedValue::ManagedValue can be used to add arbitrary cleanups. We want
methods that add cleanups, but that at the same time allow the caller to specify
what it expects the ownership of the given SILValue to be. This would then cause
an assertion to trip giving greater clarity.
rdar://29791263
In SILGen, we often times want to transform a ManagedValue, while maintaining
the underlying cleanup. The ManagedValue::transform API attempts to formalize
this pattern through the usage of std::move to create a movable rvalue, but
returning a different ManagedValue as a full value. This ensure that the
original ManagedValue is destroyed at end of statement, will allowing the
underlying cleanup to be forwarded.
From an ownership perspective, I think the majority of these cases should
actually recreate the underlying cleanup since in most cases they involve
forwarding. For today though I am using this to just formalize this pattern at
the relevant call sites.
rdar://29791263
This is a small cleanup where we are creating a cleanup for an uninitialized
buffer that will be verified as initialized later by DI and then creating a +0
unmanaged ManagedValue for the value.
This violates the "norms" of using ManagedValue in SILGen which is that one
should use the SILGenFunction::emitManaged* methods for creating/propagating
cleanups around.
Most of this involved sprinkling ValueOwnershipKind::Owned in many places. In
some of these places, I am sure I was too cavalier and I expect some of them to
be trivial. The verifier will help me to track those down.
On the other hand, I do expect there to be some places where we are willing to
accept guaranteed+trivial or owned+trivial. In those cases, I am going to
provide an aggregate ValueOwnershipKind that will then tell SILArgument that it
should disambiguate using the type. This will eliminate the ackwardness from
such code.
I am going to use a verifier to fix such cases.
This commit also begins the serialization of ValueOwnershipKind of arguments,
but does not implement parsing of value ownership kinds. That and undef are the
last places that we still use ValueOwnershipKind::Any.
rdar://29791263
This is dead code and can be re-added if it is needed. Right now though there
really isnt a ValueOwnershipKind that corresponds to deallocating and I do not
want to add a new ValueOwnershipKind for dead code.
Instead of creating an archetype builder with a module---which was
only used for protocol conformance lookups of concrete types
anyway---create it with a LookupConformanceFn. This is NFC for now,
but moves us closer to making archetype builders more canonicalizable
and reusable.
If a generic parameter was substituted for Self, we have to be careful
to not erase Self.Type down to a concrete metatype.
Also, teach the devirtualizer that a metatype of Self type does not
have an exact static type.
