In a previous commit, I banned in the verifier any SILValue from producing
ValueOwnershipKind::Any in preparation for this.
This change arises out of discussions in between John, Andy, and I around
ValueOwnershipKind::Trivial. The specific realization was that this ownership
kind was an unnecessary conflation of the a type system idea (triviality) with
an ownership idea (@any, an ownership kind that is compatible with any other
ownership kind at value merge points and can only create). This caused the
ownership model to have to contort to handle the non-payloaded or trivial cases
of non-trivial enums. This is unnecessary if we just eliminate the any case and
in the verifier separately verify that trivial => @any (notice that we do not
verify that @any => trivial).
NOTE: This is technically an NFC intended change since I am just replacing
Trivial with Any. That is why if you look at the tests you will see that I
actually did not need to update anything except removing some @trivial ownership
since @any ownership is represented without writing @any in the parsed sil.
rdar://46294760
Dynamic replacements are currently written in extensions as
extension ExtendedType {
@_dynamicReplacement(for: replacedFun())
func replacement() { }
}
The runtime implementation allows an implementation in the future where
dynamic replacements are gather in a scope and can be dynamically
enabled and disabled.
For example:
dynamic_extension_scope CollectionOfReplacements {
extension ExtentedType {
func replacedFun() {}
}
extension ExtentedType2 {
func replacedFun() {}
}
}
CollectionOfReplacements.enable()
CollectionOfReplacements.disable()
To make that work, enter appropriate scopes (ArgumentScopes and
FormalEvaluationScopes) at a bunch of places. But note that l-value
emission generally can't enter such a scope, so in generic routines
like emitOpenExistentialExpr we have to just assert that we're
already in a scope.
Instead of using composeInput(), build a tuple type containing
the element types only, dropping ownership qualifiers and
asserting that there are no inout or vararg elements.
This is correct because we already promote +0 values to +1, or
clean up +1 values that are only used as +0 as needed.
Fixes <rdar://problem/44915136>.
The constraint solver support for the Swift 3 function type behavior
has been removed, so it's no longer possible to pun the same value as
both a function taking multiple parameters and a function taking a
single tuple argument.
This means the entire parameter list is no longer a target for
substitution as a single value, so the most general form of a function
value passes each parameter indirectly instead of passing a single
tuple parameter indirectly.
Now that we handle the top-level parameter list specially, we never
end up with non-materializable tuples here, or other odd cases like
one-element tuples, so a bunch of complexity can be eliminated.
Treat the top level of the parameter list specially, instead of
looking at FunctionType::getInput().
There are three cases where we don't translate parameters 1-1:
- Imploding the parameter list into a single value when reabstracting
a function with the opaque abstraction pattern. This will go away
once Swift 3 compatibility is fully removed.
- Exploding the parameter list from a single value. This is the dual of
the above.
- Exploding the parameter list for an SE-0110 "tuple splat" conversion.
This is the one case that will need to be supported on an on-going
basis, but it is not too bad to handle directly.
This eliminates the only usage of AbstractionPattern::dropLastTupleElement().
For now, we keep the argument tuple-based entry points in TransformArguments
as well, because they're used by re-abstraction thunks. Those require a bit more
refactoring.
Most of this patch is just removing special cases for materializeForSet
or other fairly mechanical replacements. Unfortunately, the rest is
still a fairly big change, and not one that can be easily split apart
because of the quite reasonable reliance on metaprogramming throughout
the compiler. And, of course, there are a bunch of test updates that
have to be sync'ed with the actual change to code-generation.
This is SR-7134.
This is a longstanding gap in the implementation that quite possibly
never bit anyone in the wild. I've only gotten around to implementing
it now because this same code path will be used to reabstract inout
yields. That means that, rather than only affecting functions with
an abstraction difference in an inout parameter type, this can affect
all storage with any abstraction difference in the stored value type.
So it's time to fill in this gap.
- getAsDeclOrDeclExtensionContext -> getAsDecl
This is basically the same as a dyn_cast, so it should use a 'getAs'
name like TypeBase does.
- getAsNominalTypeOrNominalTypeExtensionContext -> getSelfNominalTypeDecl
- getAsClassOrClassExtensionContext -> getSelfClassDecl
- getAsEnumOrEnumExtensionContext -> getSelfEnumDecl
- getAsStructOrStructExtensionContext -> getSelfStructDecl
- getAsProtocolOrProtocolExtensionContext -> getSelfProtocolDecl
- getAsTypeOrTypeExtensionContext -> getSelfTypeDecl (private)
These do /not/ return some form of 'this'; instead, they get the
extended types when 'this' is an extension. They started off life with
'is' names, which makes sense, but changed to this at some point. The
names I went with match up with getSelfInterfaceType and
getSelfTypeInContext, even though strictly speaking they're closer to
what getDeclaredInterfaceType does. But it didn't seem right to claim
that an extension "declares" the ClassDecl here.
- getAsProtocolExtensionContext -> getExtendedProtocolDecl
Like the above, this didn't return the ExtensionDecl; it returned its
extended type.
This entire commit is a mechanical change: find-and-replace, followed
by manual reformatted but no code changes.
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.
1) It's possible to materialize a tuple value with an @escaping or
@autoclosure element in it.
I don't think this causes any bad behavior in 4.2 because these
flags have no semantic effect after the type checker, but now
I'm adding an assertion that will fire when such types are
serialized, so let's make sure it doesn't happen by explicitly
clearing out these flags when lowering tuples types.
2) It's also possible to materialize a tuple with a single vararg
element. Again, this was not a problem in 4.2, but with the above
change to start clearing tuple flags, we now end up in a
situation where the lowered type is not a tuple, because
TupleType::get() returns a ParenType if the tuple has one
element that is not vararg (which it no longer is, because we
just cleared all the flags).
Fix the second problem by treating one-element vararg tuples just
like tuples with inout, __shared and __owned elements, that is,
by always exploding them when they appear at the top level of a
function parameter list, ensuring we never try to materialize
a value whose type is the entire tuple type.
These problems all stem from the fact that lowering a function type
with the opaque abstraction pattern treats the top level argument
list as a single tuple argument. Once that is fixed, much of the
above will simplify down to assertions.
Even with an opaque abstraction pattern, we must explode a
parameter list containing __shared and __owned elements.
Otherwise, we produce invalid lowered SIL types.
Note that this is already an issue, because the stdlib has a
handful of declarations using __owned.
Modifies SILGen and the `Swift._diagnoseUnexpectedNilOptional` call to print a slightly different message for force unwraps which were implicitly inserted by the compiler for IUOs. The message is chosen based on the presence of certain flags in the `ForceValueExpr`, not on the type of the value being unwrapped.
More groundwork for protocols with superclass constraints.
In several places we need to distinguish between existential
types that have a superclass term (MyClass & Proto) and
existential types containing a protocol with a superclass
constraint.
This is similar to how I can write 'AnyObject & Proto', or
write 'Proto1 & Proto2' where Proto1 has an ': AnyObject'
in its inheritance clause.
Note that some of the usages will be revisited later as
I do more refactoring and testing. This is just a first pass.
The storage kind has been replaced with three separate "impl kinds",
one for each of the basic access kinds (read, write, and read/write).
This makes it far easier to mix-and-match implementations of different
accessors, as well as subtleties like implementing both a setter
and an independent read/write operation.
AccessStrategy has become a bit more explicit about how exactly the
access should be implemented. For example, the accessor-based kinds
now carry the exact accessor intended to be used. Also, I've shifted
responsibilities slightly between AccessStrategy and AccessSemantics
so that AccessSemantics::Ordinary can be used except in the sorts of
semantic-bypasses that accessor synthesis wants. This requires
knowing the correct DC of the access when computing the access strategy;
the upshot is that SILGenFunction now needs a DC.
Accessor synthesis has been reworked so that only the declarations are
built immediately; body synthesis can be safely delayed out of the main
decl-checking path. This caused a large number of ramifications,
especially for lazy properties, and greatly inflated the size of this
patch. That is... really regrettable. The impetus for changing this
was necessity: I needed to rework accessor synthesis to end its reliance
on distinctions like Stored vs. StoredWithTrivialAccessors, and those
fixes were exposing serious re-entrancy problems, and fixing that... well.
Breaking the fixes apart at this point would be a serious endeavor.
We used a substitution map derived from a thunk that might have been
created in a different function if that other function used the same
thunk type.
Instead use a substitution map that was derived from the
current functions generic environment.
rdar://41331672
SR-8064
If the derived class is final and the base class is not, the
protocol requirement can be witnessed by a non-required
initializer. Non-required initializers have initializing
but not allocating entry points in the vtable.
The fix here statically dispatches to the allocating
initializer instead. The test verifies that the allocating
entry point uses alloc_ref_dynamic, so you will get an
instance of the correct subclass.
This fix does not handle the resilient case where the
conformance is defined in a different module, and the original
module adds an override of the convenience init later.
I filed <rdar://problem/40639124> to track the resilient case.
Fixes <rdar://problem/40003840>.
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
