This calculates a result directly from the function's result type
instead of checking a bit that was previously set by the type
checker. Also, always returns true for constructors to simplify
some callers.
Previously we returned a subscript member locator for an apply of a
subscript expr, which is incorrect because the callee is the function
returned from the subscript rather than the subscript itself.
The implicit TypeExprs for function builders were getting inconsistently set
types, which would sometimes be the metatype and sometimes not be the
metatype, leading to a crash in the new test code.
When we perform constraint generation while solving, capture the
type mappings we generate as part of the solver scope and solutions,
rolling them back and replaying them as necessary. Otherwise, we’ll
end up with uses of stale type variables, expression/parameter/type-loc
types set twice, etc.
Fixes rdar://problem/50390449 and rdar://problem/50150314.
A substantial amount of this patch goes towards trying to get at least
minimal diagnostics working, since of course I messed up the rule a few
times when implementing this.
rdar://50149837
Since we short-circuit in the function builder application when we
hit something we cannot translate, relying on that visitor to
detect 'return' statements (which disable the application) is bogus.
Use a separate, earlier visitor to find 'return' statements consistently.
Fixes rdar://problem/50266341.
Use the opened type from the callee declaration to open up references to
generic function builders that contain type parameters. This allows general
use of generic function builders.
If a function builder contains a buildIf function, then "if" statements
will be supported by passing an optional of the "then" branch.
"if" statements with an "else" statement are unsupported at present.
When calling a function whose parameter specifies a function builder
with a multi-statement closure argument, transform the closure into
a single expression via the function builder. Should the result
type checker, replace the closure body with the single expression.
- Add a precondition on `doesDeclRefApplyCurriedSelf` to expect
a member decl, and rename it to make the precondition explicit.
- Don't assume that not having a base type means this isn't a member
reference, as member references to static operators don't have base
types.
Resolves SR-10843.
Correct a regression related to use of partially applied initializers,
which should be rejected only if it happens in a delegation chain.
Resolves: [SR-10837](https://bugs.swift.org/browse/SR-10837)
Resolves: rdar://problem/51442825
Use this function to replace various places where the logic is
duplicated.
In addition, isolate the logic where subscripts are treated as having
curried self parameters to CalleeCandidateInfo, as their interface types
don't have a curried self, but get curried with self by
CalleeCandidateInfo. Ideally we'd fix this by having a subscript's
interface type be curried with self, but given that most of this CSDiag
logic should be going away, this may not be necessary.
Introduce a fix to detect and diagnose situations when omitted
generic arguments couldn't be deduced by the solver based on
the enclosing context.
Example:
```swift
struct S<T> {
}
_ = S() // There is not enough context to deduce `T`
```
Resolves: rdar://problem/51203824
While computing a type of member via `getTypeOfMemberReference`
let's delay opening generic requirements associated with function
type until after self constraint has been created, that would give
a chance for contextual types to get propagated and make mismatch
originated in generic requirements much easier to diagnose.
Consider following example:
```swift
struct S<T> {}
extension S where T == Int {
func foo() {}
}
func test(_ s: S<String>) {
s.foo()
}
```
`foo` would get opened as `(S<$T>) -> () -> Void` and contextual `self`
type is going to be `S<String>`, so applying that before generic requirement
`$T == Int` would make sure that `$T` gets bound to a contextual
type of `String` and later fails requirement constraint `$T == Int`.
This is much easier to diagnose comparing to `$T` being bound to
`Int` right away due to same-type generic requirement and then
failing an attempt to convert `S<String>` to `S<Int>` while simplifying
self constraint.
Resolves: rdar://problem/46427500
Resolves: rdar://problem/34770265
Currently we check that the fixes share the same anchor, however this
doesn't account for the case where, given an ApplyExpr, one fix is
anchored on its function expr, and another is anchored on the apply
itself (because the former fix might be looking at the callee's
requirements, and the latter fix might be looking at an argument of
the call).
This commit changes the logic such that we check that fixes share the
same callee locator, which covers the above case. In addition, now
that we have the callee locator, we can use this to find the overload
directly.
This commit adds `ConstraintSystem::getCalleeLocator`, which forms a
locator that describes the callee of a given expression. This function
is then used to replace various places where this logic is duplicated.
This commit also changes the conditions under which a ConstructorMember
callee locator is formed. Previously it was formed for a CallExpr with a
TypeExpr function expr. However, now such a locator is formed if the
function expr is of AnyMetatypeType. This allows it to be more lenient
with invalid code, as well as work with DotSelfExpr.
Resolves SR-10694.
