Pull the entirety of type checking for for-each statement headers (i.e., not the
body) into the constraint system, using the normal SolutionApplicationTarget-based
constraint generation and application facilities. Most of this was already handled
in the constraint solver (although the `where` filtering condition was not), so
this is a smaller change than it looks like.
wrapper original wrapped value expression inside of CSApply.
This prevents type checking the synthesized backing storage initializer
twice - once with the original expression and again with the placeholder.
Type erasure requires a circular construction by its very nature:
@_typeEraser(AnyProto)
protocol Proto { /**/ }
public struct AnyProto : Proto {}
If we eagerly resolve AnyProto, the chain of resolution steps that
deserialization must make goes a little something like this:
Lookup(Proto)
-> Deserialize(@_typeEraser(AnyProto))
-> Lookup(AnyProto)
-> DeserializeInheritedStuff(AnyProto)
-> Lookup(Proto)
This cycle could be broken if the order of incremental inputs was
such that we had already cached the lookup of Proto.
Resolve this cycle in any case by suspending the deserialization of the
type eraser until the point it's demanded by adding
ResolveTypeEraserTypeRequest.
rdar://61270195
Currently `simplifyAppliedOverloads` depends on
the order in which constraints are simplified,
specifically that a lookup constraint for a
function gets simplified before the applicable
function constraint. This happens to work out
just fine today with the order in which we
re-activate constraints, but I'm planning on
changing that order.
This commit changes the logic such that it it's no
longer affected by the order in which constraints
are simplified. We'll now run it when either an
applicable function constraint is added, or a new
bind overload disjunction is added. This also
means we no longer need to run it potentially
multiple times when simplifying the applicable fn.
Use `TypeChecker::checkDeclarationAvailability` instead of `isDeclAvailable`,
that is a proper API endpoint which does flag checking before calling
`isDeclAvailable` internally.
Checking for `-disable-availability-checking` in
`ConstraintSystem::isDeclUnavailable` caused a regression with
obsolete/introduced checking. Let's rely on
`DeclAttributes::isUnavailable` and `TypeChecker::isDeclAvailable`
to do the right thing instead.
Resolves: rdar://problem/60898369
Property wrappers are allowed to infer the type of a variable, but this
only worked when the property wrapper was provided with an explicit
initialization, e.g.,
@WrapsAnInt() var x // infers type Int from WrapsAnInt.wrappedValue
However, when default initialization is supported by the property wrapper,
dropping the parentheses would produce an error about the missing type
annotation
@WrapsAnInt var x
Make this second case behave like the first, so that default initialization
works consistently with the explicitly-specified version.
Fixes rdar://problem/59471019.
It's allowed to convert a single statement closure from `(...) -> T` to `(...) -> Void`
_only_ if there is no explicit `return` in the body.
Resolves: [SR-12277](https://bugs.swift.org/browse/SR-12277)
Resolves: rdar://problem/52204414
Make sure that we're resolving types and patterns using the
PatternBindingDecl context, both for the type resolver context and the
contextual pattern used for pattern resolution.
Fixes a regression with implicitly-unwrapped options reported as
SR-11998 / rdar://problem/58455441.
For some reason, the changed caller in CS wasn't actually going to use any of the types in the constraint system from the entrypoint it was calling. Switch over to using the constraint-system-based entrypoint so we can pick up expression types consistently. Then, move the TypeChecker entrypoint onto ConstraintSystem to reduce the duplication here.
The remaining callers of buildCheckedRefExpr should be migrated.
Consider following example:
```swift
struct MyType<TyA, TyB> {
var a : TyA, b : TyB
}
typealias B<T1> = MyType<T1, T1>
_ = B(a: "foo", b: 42)
```
Here `T1` is equal to `TyA` and `TyB` so diagnostic about
conflicting arguments ('String' vs. 'Int') should only be
produced for "representative" `T1`.
Reverts apple/swift#30006. It caused a regression that we'd like to address before re-landing:
```swift
struct X {
var cgf: CGFloat
}
func test(x: X?) {
let _ = (x?.cgf ?? 0) <= 0.5
}
```
This reverts commit 0a6b444b49.
This reverts commit ed255596a6.
This reverts commit 3e01160a2f.
This reverts commit 96297b7e39.
Resolves: rdar://problem/60185506
This is a follow up to changes related to contextual availability
(https://github.com/apple/swift/pull/29921) which increased score
for unavailable declarations only if they were overloaded but
overlooked a case of a single unavailable choice.
Resolve: rdar://problem/60047439
doesn't conform to the associatedtype's protocol (only in diagnostic mode).
This allows the solver to find solutions for more cases involving requirement
failures for dependent member types without special cases across the solver
that check for dependent member types with no type variables.
This is something I noticed by inspection while working on
<https://bugs.swift.org/browse/SR-75>.
Inside a static method, 'self' is a metatype value, so
'self.instanceMethod' produces an unbound reference of type
(Self) -> (Args...) -> Results.
You might guess that 'super.instanceMethod' can similarly
be used to produce an unbound method reference that calls
the superclass method given any 'self' value, but unfortunately
it doesn't work.
Instead, 'super.instanceMethod' would produce the same
result as 'self.instanceMethod'. Maybe we can implement this
later, but for now, let's just diagnose the problem.
Note that partially-applied method references with 'super.'
-- namely, 'self.staticMethod' inside a static context, or
'self.instanceMethod' inside an instance context, continue
to work as before.
They have the type (Args...) -> Result; since the self value
has already been applied we don't hit the representational
issue.
Rather than re-walk the pattern to create type bindings for the variables
that show up in the pattern, assign types to each of the variables as part
of constraint generation for the pattern. Only do this in contexts
where we will need the types, e.g., function builders.
Consider following example:
```swift
struct MyType<TyA, TyB> {
var a : TyA, b : TyB
}
typealias B<T1> = MyType<T1, T1>
_ = B(a: "foo", b: 42)
```
Here `T1` is equal to `TyA` and `TyB` so diagnostic about
conflicting arguments ('String' vs. 'Int') should only be
produced for "representative" `T1`.
Currently constraint solver is only capable of detecting universally unavailable
overloads but that's insufficient because it's still possible to pick a contextually
unavailable overload choice which could be better than e.g. generic overload, or
one with defaulted arguments, marked as disfavored etc.
Let's introduce `ConstraintSystem::isDeclUnavailable` which supports both universal
and contextual unavailability and allow constraint solver to rank all unavailable
overload choices lower than any other possible choice(s).
Resolves: rdar://problem/59056638
