Opaque return types are special type declarations that have it
own nested generic signature. Thus, given this:
```
protocol P<A> { associatedtype A: ~Copyable }
func f<T: ~Copyable>() -> some P<T> {}
```
The generic signature for f is <T where T Escapable>, and
for the opaque return type, its nested signature ends up as
```
<X where X: P, X.A == T>
```
With SE-503, we will now also expand a default for the suppressed
primary associated type, so the signature after expansion becomes
```
<X where X: P, X.A == T, X.A: Copyable>
```
It would be smarter to effectively have this rule
```
X.A == T, T: ~Copyable
----------------------
X.A: ~Copyable
```
where we infer the inverse on X.A to cancel-out the
expanded default X.A: Copyable. We already do this for
two in-scope type parameters, and it would be better if
we did it if one side was out-of-scope, but that would
be source-breaking to do in general.
In the case of opaque return types, the fact that
it has a nested generic signature seems more an
artifact of the implementation. There also is little
risk of source break, as the only kinds of same-type
requirements that can appear are from parameterized
protocol type.
The experimental suppressed associated types prior to
SE-503 wouldn't be broken by this change, as they do
not infer defaults that need suppression, and we only
filter-out requirements from defaults expansion, rather
than explicitly-written ones.
rdar://175500824
There's a need for more control over how default requirements
for conformance to Copyable/Escapable are expanded, and
subsequently how inverses are applied or inferred to cancel-out
those defaults.
The pattern of `/*applyInverses*/BOOL` is insufficient, so this
is a refactoring to grow that into a proper type that carries
an option that can be used in some future scenario about inferring
inverses for opaque return types.
Some requirement machine work
Rename requirement to Value
Rename more things to Value
Fix integer checking for requirement
some docs and parser changes
Minor fixes
This corresponds to the parameter-passing convention of the Itanium C++
ABI, in which the argument is passed indirectly and possibly modified,
but not destroyed, by the callee.
@in_cxx is handled the same way as @in in callers and @in_guaranteed in
callees. OwnershipModelEliminator emits the call to destroy_addr that is
needed to destroy the argument in the caller.
rdar://122707697
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
Distributed protocol requirements don't have associated SILFunction,
let's introduce a more flexible way to define it that collects only
the information necessary for the function to become accessible.
Given the following protocol:
```
protocol Greeter : DistributedActor {
distributed func greet()
}
```
The changes make it possible to synthesize a distributed accessor
thunk for the requirement `greet` which would be dispatched to the
underlying concrete actor implementation at runtime.
Since distributed actors can now be generic over actor system
it's no longer guaranteed for concrete decoder to be present,
we need to handle that case specifically during accessor emission.
Adding a few more updates to places where the ABI Alignment functions
changed. `getABITypeAlignment` was replaced with `getABITypeAlign`,
which returns an `llvm::Align` instead of an unsigned int.
LLVM deprecated, renamed, and removed a bunch of APIs. This patch
contains a lot of the changes needed to deal with that.
The SetVector type changed the template parameters.
APInt updated multiple names, countPopulation became popcount,
getAllOnesValue became getAllOnes, getNullValue became getZero, etc...
Clang type nullability check stopped taking a clang AST context.
The LLVM IRGen Function type stopped exposing basic block list directly,
but gained enough API surface that the translation isn't too bad.
(GenControl.cpp, LLVMMergeFunctions.cpp)
llvm::Optional had a transform function. That was being used in a couple
of places, so I've added a new implementation under STLExtras that
transforms valid optionals, otherwise it returns nullopt.
Arguments that have been loaded due to underlying method conversion
have to be destroyed after the call otherwise they are going to leak.
Resolves: https://github.com/apple/swift/issues/65853
Resolves: rdar://109207043
- SILPackType carries whether the elements are stored directly
in the pack, which we're not currently using in the lowering,
but it's probably something we'll want in the final ABI.
Having this also makes it clear that we're doing the right
thing with substitution and element lowering. I also toyed
with making this a scalar type, which made it necessary in
various places, although eventually I pulled back to the
design where we always use packs as addresses.
- Pack boundaries are a core ABI concept, so the lowering has
to wrap parameter pack expansions up as packs. There are huge
unimplemented holes here where the abstraction pattern will
need to tell us how many elements to gather into the pack,
but a naive approach is good enough to get things off the
ground.
- Pack conventions are related to the existing parameter and
result conventions, but they're different on enough grounds
that they deserve to be separated.
Kavon Farvardin
Konrad `ktoso` Malawski
Slava Pestov
Anthony Latsis
Konrad `ktoso` Malawski
Kuba Mracek
Alejandro Alonso
Akira Hatanaka
Tim Kientzle
Pavel Yaskevich
Arnold Schwaighofer
Mishal Shah
Evan Wilde
John McCall