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.
This assert was correctly catching the fact that `-target-variant` is not being
normalized at the same time as `-target` when building arm64e modules from
swiftinterface. That should be fixed, but at the moment it isn't causing any
concrete harm and the assertion fails when building against the SDKs included
with the latest Xcode 16 betas.
Resolves rdar://133020098.
