If a base class initializer was not generic but had a contextual 'where'
clause, we would unconditionally inherit the 'where' clause in the override as
part of the fix for another issue (https://bugs.swift.org/browse/SR-14118).
However, it is possible that some of those requirements are satisfied by
the derived class itself. For example:
class Base<T> {
init() where T : AnyObject {}
}
class Derived : Base<AnyObject> {}
In this case, the implicit override Derived.init() has no generic requirements
at all. We used to assert because we would create a GSB with no generic
parameters.
It was also possible for a base class initializer to have generic
requirements that are not satisfied by the derived class. In this case,
we need to drop the initializer from consideration altogether.
While I'm here, I improved the comments in computeDesignatedInitOverrideSignature(),
which is the new name for configureGenericDesignatedInitOverride().
Fixes rdar://problem/77285618.
Attempting to conform an actor to a global actor isolated protocol
creates a clash in isolation when members are accessed so, let's
detect and diagnose that.
Resolves: rdar://75849035
This change separates emission of the diagnostics like:
```
unnecessary check for 'Platform'; enclosing scope ensures guard will always be true
```
from the deployment target of the current compilation. Instead, these diagnostics will only be emitted if the enclosing scope guard is explicitly specified by the user with an `#availability` attribute.
This fixes cases like the following:
```
@available(macOS 11.0, *)
class Foo {
func foo() {
if #available(macOS 11.1, *) {}
}
}
```
Compiling this with `-target x86_64-apple-macos11.2` results in:
```
warning: unnecessary check for 'macOS'; enclosing scope ensures guard will always be true
if #available(macOS 11.1, *) {}
.../test.swift:2:7: note: enclosing scope here
class Foo {
```
Even though in source-code the enclosing scope (`Foo`) of this guard does not ensure it will always be true.
This happens because availability range is propagated by intersecting ranges top-down from the root `TypeRefinementContext`, which is defined by the deployment target, causing the availability range on class `Foo` to become `11.2`.
Users may be sharing the same piece of source-code across different projects with their own respective deployment targets which makes such target-dependent warnings confusing at some times, and not-useful at others.
We should rather have the warning simply reflect what is in the source.
Resolves rdar://77607488
In overloaded context it's possible that there is an overload that
expects a closure but it can have other issues e.g. different number
of parameters, so in order to pick a better solution let's always
increase a score for overloads where closure is matched against a
non-function type parameter.
Disable non-Optional "assumption" warning for ambiguities related to a
static member lookup in generic context because it's possible to declare
a member with the same name on a concrete type and in an extension of a
protocol that type conforms to e.g.:
```swift
struct S : P { static var test: S { ... }
extension P where Self == S { static var test: { ... } }
```
And use that in an optional context e.g. passing `.test`
to a parameter of expecting `S?`.
Resolves: rdar://77700261
Remove the `TypeCheckExprFlags::AllowUnresolvedTypeVariables` flag, fixing another occurance of rdar://76686564 (https://github.com/apple/swift/pull/37309)
This does not break anything in the test suite, so I think the removal of the flag is fine.
Resolves rdar://76686564 and rdar://77659417
Not all of the pre-check errors could be diagnosed by re-running
`PreCheckExpression` e.g. key path expressions are mutated to
a particular form after an error has been produced.
To make the behavior consistent, let's allow pre-check to emit
diagnostics and unify pre-check and constraint generation fixes.
Resolves: rdar://77466241
A type representing a closure expression is always bound to its
"inferred" type based on the body, so contextual bindings just
serve as a trigger to "resolve" a closure. Let's not attempt any
subtype/supertype inference for a type variable representing a
closure since if "direct" bindings have failed, it wouldn't be bound
to such types regardless.
Resolves: rdar://problem/77022842
According to Pavel, we want to eliminate allowing unresolved variables as much as possible. Removing this flag doesn’t break any test cases (at least not in a meaningful way) and fixes a crasher, so it seems reasonable to remove it.
Fixes rdar://76686564
Because we are completing inside a result builder, we are never calling into `typeCheckExpression` and thus never call into `typeCheckForCodeCompletion` before `fallbackTypeCheck` (SR-14601).
This works fine in most cases, but in the added test case, we are hitting an assertion because the specifiers are not correctly erased from the `ClosureExpr` before re-typechecking for completion. Erasing them before fixes the test case until the underlying issue described above is fixed.
Fixes rdar://76710904 [SR-14494]
`async` from contextual types to closure types.
This preserves the behavior that `async` is propagated to closures that
should inherit the surrounding actor context, even if the closure is an
argument to a reasync function.
When `nil` is passed as an argument to call with multiple overloads
it's possible that this would result in ambiguity where matched
expected argument type doesn't conform to `ExpressibleByNilLiteral`.
To handle situations like this locator for contextual mismatch
has to be adjusted to point to the call where `nil` is used, so
`diagnoseAmbiguityWithFixes` can identify multiple overloads and
produce a correct ambiguity diagnostic.
Resolves: rdar://75514153
