Verify the behavior of swift_storeEnumTagMultiPayload in the face of
small payload sizes (8 bits) and many empty cases (more than 2^8).
Additional test of the behavior that was fixed at
https://github.com/apple/swift/pull/42131
When storing a tag into a multi-payload enum for an empty case via
swift_storeEnumTagMultiPayload, the tag is split between the storage for
payloads (i.e. the associated values of the non-empty cases) and the
storage for tags (i.e. the integers which refer to the non-empty cases).
Typically, the number of non-empty cases (i.e. one beyond the tag
that refers to the last non-empty case) is stored into the tag storage
and the integer which distinguishes which among the empty cases the enum
is in is stored into storage for payloads. When the enum is small,
however--specifically, when the payload size is less than four
bytes--that information is packaged differently via masking.
Previously, there was a problem with that masking. While the value
stored into the tag storage was correct (and correctly indicated that
the enum was in some empty case), the value stored into the payload
storage was not. The result was that which empty case an enum was in
would be corrupted.
Here, that is fixed by fixing the masking.
rdar://87914343
`typeEraseExistentialSelfReferences` shouldn't account for
contextual signature because that signature could have
generic parameters of it's own unrelated to the reference
which would be located before generic parameters of the
member, e.g. when the code is located in a protocol extension,
which invalidates the assumption that `Self` is located at
depth = 0, index = 0.
Resolves: rdar://91110069
- Don't pass 'verify' since it's now the default
- Update tests where diagnostics changed in a correct way to pass 'on' instead
- Delete compiler_scale/explicit_requirements_perf.swift since it's not testing anything with the requirement machine
When analyzing a struct's layout to determine whether it contains a
single non-empty field, bail upon encountering a field that is not ABI
accessible.
Previously, rather than bailing (though that was the intent), the field
was ignored. The result was that struct's with a single non-empty field
and any number of ABI inaccessible fields would be treated as if they
only had a single non-empty field. Trouble ensued.
rdar://79513293
Apparently, RemoteMirror chokes on certain MPEs with generic payload types.
It does not recognize the generic payload type so ends up defaulting to a
zero size. This causes the overall enum size to be miscalculated unless there
is another non-generic payload that's at least as large.
The case below requires us to reprocess the metatype to "thicken" it.
That process inadvertently lost information about the depth of generic
nesting, which caused the RemoteMirror to be unable to resolve the type of
`C.E.t` at runtime.
```
class C<T> {
enum E<T> {
case t(T)
case u(Int)
}
var e: E<T>?
}
```
Solution: add code to the thickening logic to recursively thicken
parent types to preserve the nesting of generics.
Resolves rdar://90490128
This effectively reverts 6823744779
The blanket removal of isolation in default-value expressions had
unintented consequences for important workflows. It's still
a problem that needs to be addressed, but we need to be more precise
about the problematic situations.
Complete support is behind a flag, because it can result in a non-convergent
rewrite system if the opaque result type has a recursive conformance of its
own (eg, `some View` for SwiftUI's View protocol).
Without the flag, it's good enough for simple examples; you just can't have
a requirement that mentions a nested type of a type parameter equated to
the concrete type.
Fixes rdar://problem/88135291, https://bugs.swift.org/browse/SR-15983.
This hooks up call argument position completion to the typeCheckForCodeCompletion API to generate completions from all the solutions the constraint solver produces (even those requiring fixes), rather than relying on a single solution being applied to the AST (if any).
Co-authored-by: Nathan Hawes <nathan.john.hawes@gmail.com>
Fixes a crash during diagnostics by not assuming that optional chain
would always produce an optional type, which is not true because in
error scenarios it could get assigned an invalid type from context.
Resolves: rdar://85516390
