When a `FixedArray`'s fixed size is 1, it looks like `[1 x %Ty]`. Given
an array's address, performing an operation on each element's address
entail's indexing into the array to each element's index to produce an
element's address for each index. That is true even when the array
consists of a single element. In that case, produce an address for that
single element by indexing to index 0 into each passed-in array.
rdar://151726387
`substBase` here can contain type variables or placeholders, avoid
using them as the original ErrorTypes since ErrorTypes cannot be
solver-allocated currently. This only affects type printing so
shouldn't matter much.
Escaping solver-allocated types into a nested allocation arena is
problematic since we can e.g lazily compute the `ContextSubMap` for a
`NominalOrBoundGenericNominalType`, which is then destroyed when we
exit the nested arena. Ensure we don't pass any types with type
variables or placeholders to `typesSatisfyConstraint`.
rdar://152763265
LifetimeDependenceInsertion inserts mark_dependence on token result of a begin_apply
when it yields a lifetime dependent value. When such a begin_apply gets inlined,
the inliner can crash because of the remaining uses of the token result.
Fix this by inserting mark_dependence on parameter operands that are lifetime dependence sources
and deleting the mark_dependence on token results in the inliner.
Fixes rdar://151568816
This can return ErrorType if the AST is invalid.
A handful of callers handle the ErrorType result, but most don't,
blindly assuming the result is always a nominal type. This resulted
in a crash in at least one test case.
Lift the burden from callers by always returning a nominal type here.
These contain a mix of crashers that may or may not crash under
non-asserts builds, avoid testing them for non-asserts builds. When
fixed, they'll receive non-assert coverage.
It is a maintenance burden and having the legacy driver exist in a simplified state reduces the possibility of things going wrong and hitting old bugs.
Every `LowerType::visit*` function eventually calls through to a
`LowerType::handle*` function. After
https://github.com/swiftlang/swift/pull/81581, every
`LowerType::handle*` needs to set the `hasPack` flag based on the
passed-in type by calling `mergeHasPack`. Add the missing call in the
`handleAggregateByProperties` function.
rdar://152580661
Fixes a crash on invalid. The previous logic was causing a label
mismatch constraint fix to be recorded for an unlabeled trailing closure
argument matching a variadic paramater after a late recovery argument
claim in `matchCallArgumentsImpl`, because the recovery claiming skips
arguments matching defaulted parameters, but not variadic ones. We may
want to reconsider that last part, but currently it regresses the
quality of some diagnostics, and this is a targeted fix.
The previous behavior is fine because the diagnosis routine associate
with the constraint fix (`diagnoseArgumentLabelError`) skips unlabeled
trailing closures when tallying labeling issues — *unless* there are no
other issues and the tally is zero, which we assert it is not.
Fixes rdar://152313388.
The proposal states that this should work, but this was never
implemented:
protocol P<A> {
associatedtype A
}
struct S: P<Int> {}
- Fixes https://github.com/swiftlang/swift/issues/62906.
- Fixes rdar://91842338.
While deserializing AST function types FunctionType and GenericFunctionType which include
lifetime dependencies and an implicit self parameter, we don't correctly populate
ASTExtInfoBuilder.lifetimeDependencies. We end up reading one dependency less due to
incorrect index calculation.
Unlike SILFunctionType, AST function types FunctionType and GenericFunctionType
do not include implicit self in their param list. They represent methods with
implicit self as like: `(Self) -> (Args...) -> Result` and don't have any information
to indicate they may have implicit self. Since we use number of parameters while
deserializing lifetime dependencies, we go wrong for such function types.
Serialize the length of parameter indices, so that lifetime dependencies can be
deserialized to that length.
rdar://151768216