While materializing one metadata pack, another pack may need to be
materialized. When that happens, the inner pack's dynamically sized
allocation must be deallocated within the same dominance scope.
The CFG within which the inner dynamically sized pack is allocated isn't
visible from SIL; that explains why the existing infrastructure around
`de`/`alloc_pack_metadata` instructions fails to produce a deallocation
at the appropriate point.
In the fullness of time, this emitted code should be optimized such that
the inner loop is hoisted out of its current outer loop.
rdar://141718098
Although it's not used anymore we still have to support it to be able to read old Swift.interface files which still contain the builtin.
rdar://144781646
Rather than the block that we _think_ we're emitting into, use the block
we're actually emitting into. These aren't the same because callees
can and do introduce control flow.
We can't always use an outlined function, destroy_addr's implementation
already handles cases where this is true (such as opened archetypes).
rdar://143456806
Zero sized fields are messing up the offset calculations when we import
C++ fields to Swift. We assume that the size of the field is determined
by the type of the field. This is not true for fields marked with
no_unique_address. Those fields can have 0 size while the
sizeof(decltype(field)) is still 1.
rdar://143907490
This relands commit 45d4648bdb while ensuring that
sanityCheckCachedType uses the exact same condition (now factored into a helper
function) as createType() to determine whether a type is sized or not.
rdar://143833326
PR #78467 omitted certain fields from the FieldDescriptor list,
but did not update the count of fields that's emitted
just before that list.
Update the count so it matches the number of field descriptors
we actually emit.
Resolves rdar://143402921
`[[fallthrough]]` must be followed by a `case` label. The current use in
IRGen did not follow this requirement. Adjust the logic to match the
requirement. This fixes a few diagnostics that MSVC emitted for this
error.
The problem with `is_escaping_closure` was that it didn't consume its operand and therefore reference count checks were unreliable.
For example, copy-propagation could break it.
As this instruction was always used together with an immediately following `destroy_value` of the closure, it makes sense to combine both into a `destroy_not_escaped_closure`.
It
1. checks the reference count and returns true if it is 1
2. consumes and destroys the operand
with sending results:
- The sending result mangling was added in the 6.0 runtime, so demangling
cannot be used to produce this metadata when targeting an earlier
runtime.
- The combination of a sending result with isolation requires the 6.1
runtime to successfully demangle, due to a bug in the 6.0 demangler.
This is used for synthetic uses like _ = x that do not act as a true use but
instead only suppress unused variable warnings. This patch just adds the
instruction.
Eventually, we can use it to move the unused variable warning from Sema to SIL
slimmming the type checker down a little bit... but for now I am using it so
that other diagnostic passes can have a SIL instruction (with SIL location) so
that we can emit diagnostics on code like _ = x. Today we just do not emit
anything at all for that case so a diagnostic SIL pass would not see any
instruction that it could emit a diagnostic upon. In the next patch of this
series, I am going to add SILGen support to do that.
Correct the IRGen for the standard library. The thinko here assumed that the else case would be evaluated for the standard library build. We ended up incorrectly handling the well-known VWTs from the runtime when building the standard library.
