To determine the correct enum layout, we first count various
categories of cases. Before, we counted indirect generic cases as
"generic", but regular "generic" cases can't export spare bits.
Change this to count "indirect" cases as a separate category.
In particular, this ensures that fully-indirect enums use
spare bits from the pointers even when some or all of the cases
are generic.
Resolves rdar://133890406
The first word in a class existential is the class pointer itself.
This pointer exposes spare bits differently depending
on the platform, which becomes apparent when you try to reflect
an Optional carrying such an MPE.
Add new test cases and some logic to zero out the first
word of spare bit information only on platforms with 8-byte pointers.
Such destroys mark the lifetime end of their operands along their
availability boundary. They are currently inserted in this test case
by the ClosureLifetimeFixup pass, but in the fullness of time they will
be present for every value which is not explicitly destroyed (that's
what complete OSSA lifetimes is mostly about).
Currently, such destroys are diagnosed by DiagnoseUnreachable. Fix the
diagnostic pass not to diagnose these valid instructions.
rdar://137960229
Class existentials expose spare bits from all of the pointers, not just the first one.
Due to a bad bug here, we were properly exposing spare bits from the first pointer,
but then claiming that all bits of subsequent pointers were spare.
This accidentally resulted in the correct operation on 64-bit targets
(it picked the highest-order spare bit, which happened to be spare
in both the broken mask and the correct mask). But on 32-bit targets,
this exposed the high-order bits of pointers, which is incorrect.
Expand the test a bit while we're here as well.
Resolves rdar://132715829
This plugs a hole where we failed to recognize a CF type when it
appeared as the payload of an enum stored as a property. Curiously,
RemoteMirror is able to reflect this when the enum appears by itself,
just not when it's stored as a property.
The simplest fix is to hook into the TypeInfo calculation which
computes a TypeInfo (basically, the tree of fields) from a TypeRef
(basically, the name of the type, including generic context).
Specifically, we sometimes end up here with a "type alias" that
none of the lookup support seems to be able to handle. Fortunately,
these aliases demangle into a pretty predictable shape, so this
just pattern-matches the specific demangle tree shape to recognize
these as "type aliases in the `__C` module whose name starts with `CF`
and ends with `Ref`".
Resolves rdar://82465109
I think the original idea was to elide `Array<$T>` if there is
a binding a resolved generic arguments i.e. `Array<Float>`, but
the check doesn't account for the fact that bindings could be
of different kinds and there are some implicit conversions that
could be missed if we remove the bindings.
For example, given the following constraints:
`Array<$T0> conv $T1`
`$T1 conv Array<(String, Int)>`
`$T0` can be a supertype of `Array<$T0>` and subtype of `Array<(String, Int)>`.
The solver should accept both types as viable bindings because the
`$T0` could be bound to `(key: String, value: Int)` and that would
match `Array<(String, Int)>` conversion.
- Don't attempt to insert fixes if there are restrictions present, they'd inform the failures.
Inserting fixes too early doesn't help the solver because restriction matching logic would
record the same fixes.
- Adjust impact of the fixes.
Optional conversions shouldn't impact the score in any way because
they are not the source of the issue.
- Look through one level of optional when failure is related to optional injection.
The diagnostic is going to be about underlying type, so there is no reason to print
optional on right-hand side.
Prevents a crash when a parameter references an invalid property wrapper. The original code assumed that mutability information would always be available, but this assumption fails when the property wrapper is invalid
Resolves https://github.com/swiftlang/swift/issues/65640
`participatesInInference` is now always true for
a non-empty body, remove it along with the separate
type-checking logic such that empty bodies are
type-checked together with the context.