This fixes TypeLowering for ~Copyable generics, such as:
struct S<T: ~Copyable>: ~Copyable {
var x: T
}
extension S: Copyable where T: Copyable {}
func foo<T>(s: S<T>) -> ()
Previously, TypeLowering would ignore the implicit Copyable
requirement on the archetype 'T'.
When a closure throws a generic error type, we were retrieving the
substituted error type (involving archetypes) when we needed to be
working with the interface type.
Fixes rdar://124484012.
We want a conditionally-copyable type to still be classified as trivial in cases
where it's bitwise-copyable, has a trivial deinit, and is Copyable. The previous
implementation here only checked at the declaration level whether a type was
Copyable or not; get a more accurate answer by consulting the combination
of information in the substituted type and abstraction pattern we have
available during type lowering so that we classify definitely-copyable substitutions
of a conditionally-copyable type as trivial. Should fix rdar://123654553 and
rdar://123658878.
The main piece that's still missing here is support for closures;
they actually mostly work, but they infer the wrong isolation for
actor-isolated closures (it's not expressed in the type, so obviously
they're non-isolated), so it's not really functional. We also have
a significant problem where reabstraction thunks collide incorrectly
because we don't mangle (or represent!) formal isolation into
SILFunctionType; that's another follow-up. Otherwise, I think SILGen
is working.
rdar://119329771
This layout allows adding pre-specializations for trivial types that have a different size, but the same stride. This is especially useful for collections, where the stride is the important factor.
We were attempting to perform substitution against the original pattern
even when it didn't have a substitution map, and then trying to cover
for the resulting errors by adjusting to `any Error`... which isn't
always correct. Do the substitution only when it makes sense.
Fixes rdar://119217570 & rdar://119219214.
This peephole optimization in SILGen requires us to use the thrown
error for the context of a closure type rather than the thrown error
for the closure AST node itself.
If the pattern doesn't have any pack parameters in it anymore,
we need to recover the substituted count type from the original
count type.
Fixes rdar://problem/112065340.
Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
variadic-tuple results. There are three parts to this.
First, fix the emission of indirect result parameters to do a
proper abstraction-pattern-aware traversal of tuple patterns.
There was a FIXME here and everything.
Second, fix the computation of substituted abstraction
patterns to properly handle vanishing tuples. The previous code
was recursively destructuring tuples, but only when it saw a
tuple as the substituted type, which of course breaks on vanishing
tuples.
Finally, fix the emission of returns into vanishing tuple
patterns by allowing the code to not produce a TupleInitialization
when the tuple pattern vanishes. We should always get a singleton
element initializer in this case.
Fixes rdar://109843932, plus a closely-related test case for
vanishing tuples that I added myself.
In asserts builds, the lexicality of packs is verified via an
alternative code-path that walks into aggregates. That walk needs to
proceed through packs.
rdar://107283101
whichever case it happens to be in.
This is a basic fix so that parallel walks on tuples and function
types in the substituted type will work . Separately, though, I
do not think the places that use this really need to be passed an
orig type; this is used for computing type properties, and I am
not aware of any reason we should need an orig type to compute
type properties. Additionally, the orig types computed by this
function are not really correct because of the substitution being
done in some cases, so it'd be very nice to rip this all out.
I'm not good to look into that right now, though.
and not also drop a subst parameter.
This turned out to be more convenient for certain clients (e.g. SILGenPoly)
than requiring the full subst param list to be passed in. These clients
want to process the subst param list separately, and dropping self early
can be convenient for that. The only fundamental reason we need this
flag is for working with the orig type, so just use it for that; clients
that need to use this feature can reasonably be expected to cooperate.
This is necessary because the use patterns in SILGenPoly require
walking two orig+subst sequences in parallel, which poses problems
for a callback-centric design like the one I addded before. An
inversion of control is necessary; this is basically a manual
coroutine. But frankly it's a nicer interface than the callback
design, too; I switched the implementation of forEachFunctionParam
to use the generator just to avoid code duplication, but I might
try to remove it and switch all the clients over to the generator.
The main problems with the callback design are that (1) I wasn't
sure which values clients would want, and the result is that there
are a *lot* of parameters and (2) (relatedly) the types of those
parameters have to be written out explicitly, and some of them
are quite large. The generator code is just much nicer. Maybe
I can still give the generator a little unparameterized callback
to keep lexical loops simple.
I'll need to do this same thing for tuples. One at a time.
