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
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>.
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.
