The `__future__` we relied on is now, where the 3 specific things are
all included [since Python 3.0](https://docs.python.org/3/library/__future__.html):
* absolute_import
* print_function
* unicode_literals
* division
These import statements are no-ops and are no longer necessary.
I think that preferring identical over convertible makes sense in e.g. C++ where we have implicit user-defined type conversions but since we don’t have them in Swift, I think the distinction doesn’t make too much sense, because if we have a `func foo(x: Int?)`, want don’t really want to prioritize variables of type `Int?` over `Int` Similarly if we have `func foo(x: View)`, we don’t want to prioritize a variable of type `View` over e.g. `Text`.
rdar://91349364
A conformance requirement on a concrete type parameter is redundant if the
concrete type conforms to the protocol.
The replacement path for the conformance rule is based on a concrete
conformance rule introduced by the property map. Since the concrete
conformance rule is not associated with a requirement ID, this would
normally muffle the redundancy warning, because we don't want to
suggest removing a rule that depends on a non-redundant, non-explicit
rule.
However, concrete conformance rules don't actually appear in the
minimal signature, so skip them when computing the set of non-redundant,
non-explicit rules to ensure that the original conformance requirement
is still diagnosed as redundant.
Previously, switches over extremely large integers (e.g. i832) were
emitted when emitting switches with many spare bits. Such switches
result in unfortunate downstream codegen.
Here, for large enums (currently, more than two words) the preexisting
EnumPayload::emitCompare function is used to compare each of the enum
cases in turn with the payload's value. The result is a series of
cond_br where the conditional is made by anding together word-size
chunks of the payload value with word-size chunks of each enum case's
tag, subject to masking.
rdar://83158525
This is a follow-up to https://github.com/apple/swift/pull/40708 which only considers
closures, but it missed the case when builder is applied to function body - in such
cases the declaration context is going to be a function/getter declaration.
Resolves: rdar://91150414
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
