After #83959, we expect noncopyable OpenExistential evaluations to have an outer
FormalEvaluationScope to forward to. However, there was no such
FormalEvaluationScope while emitting a consuming switch subject, causing an assertion
failure to trip. Add a FormalEvaluationScope tightly scoped around the evaluation in
this case, fixing rdar://160080337.
closures.
The fixes for initializers are just setting the stage for doing this
properly: we should be able to just change the isolation computation
in Sema and fix up the tests.
We want to call the `bodyEmitter`, since that has the extra logic
necessary to handle `do-catch` statements. Previously this didn't
cause any issues since `hasCaseBodyVariables` would have always been
true for parsed `do-catch`s, but I'm planning on changing that.
As with SIL functions, track the parent module where a SIL global
variable was originally defined so that we can determine whether we
are outside of its original module for linkage purposes. Use this to
make sure we emit via a weak definition when emitting to a module
other than the originating module.
Fixes rdar://160153163.
Fixes a regression caused by the `self` declaration being given a `DynamicSelfType`
even though the formal type of the enclosing function sometimes still uses the
concrete base class type.
Fixes#83876 | rdar://158956768.
We were not able to use an existential as the base
of an access that strictly borrows the existential,
because SILGen's RValue emission would establish
a fresh evaluation scope just for the existential's
opening, and then copy the opened value out.
This is problematic for noncopyable existentials.
So this patch moves & adds FormalEvaluationScope's
around so they're broad enough to enable a
borrow of an existential. The idea behind this
refactoring is to establish top-level
FormalEvaluationScopes when initially creating
RValue's for Expr's in SILGen. Any more-tightly
scoped operations will already establish their own
nested scope, so this is mostly adding safe-guards.
I've limited the existentials fix to noncopyables
for now.
part of rdar://159079818
If a subscript uses a read accessor to yield a noncopyable value,
we'd emit an `end_apply` that's too tightly scoped to allow for
a subsequent borrowing access on the yielded value.
resolves rdar://159079818
Rather than just looking at top level in the module, start by searching
the type marked as `@main`. This means that a library that provides a
protocol or superclass that the `@main` type can conform to can specify
an executor in a reasonable manner.
There's no need for two separate types here. Fully separate the addressable buffer
tracking from VarLocs as well, in order to set up for a fix to addressable references
to `if let` and `guard let` bindings.
Get rid of the boolean arguments for unavailability in AvailabilityQuery's
constructors and introduce a `asUnavailable()` modifier that can be used
instead in the contexts where unavailability is relevant.
- Calls to variadic-generic protocol requirements weren't applying
substitutions properly, so expansion-sensitive types in the callee
signature weren't pairing properly with their expansions in the
caller.
- emitPackTransform had an over-destroy if the transformation function
actually emitted into the temporary element directly.
- There were some MV ownership assertions that were wrong, which
revealed that the corresponding code really didn't handle consuming/
borrowing mismatches properly at all.
- We were completely mishandled consuming packs.
Fixes#81002, #80995, and #81600.
`zeroInitializer` is blocking optimizations. It is not needed because the constructor will initialize the memory anyway.
We only need to tell mandatory passes that this memory should be treated as initialized.
At the same time, make sure we propagate contextual initializations.
I'm actually not sure this is meant to be supported, but it's fine,
we should implement it.
Fixes#80937
functions to compute them directly without a TypeLowering object, and
change a lot of getTypeLowering call sites to just use that.
There is one subtle change here that I think is okay: SILBuilder used to
use different TypeExpansionContexts when inserting into a global:
- getTypeLowering() always used a minimal context when inserting into
a global
- getTypeExpansionContext() always returned a maximal context for the
module scope
The latter seems more correct, as AFAIK global initializers are never
inlinable. If they are, we probably need to configure the builder with
an actual context properly rather than making global assumptions.
This is incremental progress towards computing this for most types
without a TypeLowering, and hopefully eventually removing TL entirely.
