`??` is overloaded on optionality of the second parameter,
prevent ranking the argument candidates for this parameter
if there are candidates that come from failable initializer
overloads because non-optional candidates are always going
to be better and that can skew the selection.
Resolves: rdar://156853018
Protocol requirement witnesses cannot only be available in a custom
availability domain if the requirement does not have the same availability
constraint.
Resolves rdar://156462516.
Make explicit "nonisolated" also not special on protocols, so a
nonisolated protocol does not suppress default isolation.
SendableMetatype is the proper way to suppress default isolation for a
protocol.
Unfortunately, these rules made it appear like issue #82168
was fixed, when in fact it was not. Keep the test case, but as a
failing test, and we'll investigate separately.
Given an explicitly-nonisolated type such as
nonisolated struct S { }
all extensions of S were also being treated as nonisolated. This meant
that being implicitly nonisolated (i.e., when you're using nonisolated
default isolation) was different from explicitly-writing nonisolated,
which is unfortunate and confusing. Align the rules, such that an
extension of S will get default isolation:
extension S {
func f() { } // @MainActor if we're in main actor default isolation
}
Extensions of nonisolated types can get default isolation from context
(e.g., @MainActor) independently. This was previously true for members,
but not conformances, and recently regressed for members. Fix the logic
to consistently allow such extensions to be default main-actor
isolated, which affects both their members and conformances.
Fixes rdar://156644976.
Since this is a C++ stdlib type we need make sure that any overloads
that use it are preferred over custom types that also conform to
`ExpressibleByStringLiteral` when argument is a string literal.
This is important for operators like `==` which could be heterogenous
and have a custom C++ type that conforms to `ExpressibleByStringLiteral`
on either side together with `std.string` i.e.
`==(std.string, const CustomString &)`, such overloads should only
be selected if argument passed to `CustomString` is non-literal because
literals are convered by a stdlib `==(std.string, std.string)` overload.
It's difficult to trigger this because the code path is only
reached for the standard operators. The issue in question was
in embedded Swift due to an unsupported usage of the ===
operator, but we expect an upcoming standard library change to
actually make us accept that code.
However, the fix should be pretty safe, even without a test case.
Fixes the crash in rdar://156095800.
This fixes a regression introduced in https://github.com/swiftlang/swift/pull/82574.
The test case demonstrates the issue: we would incorrectly choose the base class
overload of == if one of the parameters was an archetype or dynamic Self.
Fixes rdar://156454697.
Consolidate some of the closely related protocol requirement check failures and
then turn `RequirementCheck` into a proper wrapper around a union of associated
values for `CheckKind`.
NFC.
The current implementation of the check accounts only for the overload
choices present in the initial lookup but for some situations, like
bridged or optional base types, `performMemberLookup` uses a secondary
lookup as well, results of which are ignored.
Let's fold the check into `addChoice` instead and set the the flag there
to make sure that all of the choices are considered.
Resolves: rdar://143586718
Now look through other opaque return types that appear in the
underlying type. This catches various forms of recursion that
otherwise would cause a SILGen or SILOptimizer crash.
- Fixes rdar://82992151.
Use these queries to replace some duplicated code. Also, move the
`attr_inlinable_available.swift` test to the `Availability` sub-directory since
the test has more to do with availability checking than it has to do
specifically with the `@inlinable` attr.
decls that are in a main actor isolated context.
This prevents `@MainActor` from being inferred in a context where
it cannot be used, while still allowing main actor code to be used
in local contexts that are also main actor isolated.
`_openExistential` is type-checked in a special way which
means that we need to explicitly inject `nonisolated(nonsending)`
isolation when forming a reference to this builtin.
`withoutActuallyEscaping` is type-checked in a special way which
means that we need to explicitly inject `nonisolated(nonsending)`
isolation when forming a reference to this builtin.
