Try to fix constraint system in a way where member
reference is going to be defined in terms of its use,
which makes it seem like parameters match arguments
exactly. Such helps to produce solutions and diagnose
failures related to missing members precisely.
These changes would be further extended to diagnose use
of unavailable members and other structural member failures.
Resolves: rdar://problem/34583132
Resolves: rdar://problem/36989788
Resolved: rdar://problem/39586166
Resolves: rdar://problem/40537782
Resolves: rdar://problem/46211109
Fix to use subscript operator instead of spelled out name helps
to produce a solution, that makes it much easier to diagnose
problems precisely and provide proper fix-its, it also helps to
diagnose ambiguous cases, and stacks up nicely with other errors.
Sometimes constraint solver fails without producing any diagnostics,
it could happen during different phases e.g. pre-check, constraint
generation, or even while attempting to apply solution. Such behavior
leads to crashes down the line in AST Verifier or SILGen which are
hard to diagnose.
Let's guard against that by tracking if solver produced any diagnostics
upon its failure and if no errors were or are scheduled to be produced,
let's produce a fallback fatal error pointing at affected expression.
Resolves: rdar://problem/38885760
All of the open existentials should be removed, along with their
opaque value expressions, after sub-expression type-check. Because
diagnostics might pick next sub-expression from constraint and its
anchor could point to sub-expression which has only opaque value
without enclosing open existential, which is going to trip up sanitizer.
Resolves: rdar://problem/46544601
After calling `get{Possible}Type{s}WithoutApplying` types have to be
re-cached afterwards because sanitizer (run as part of the constraint
generator) can mutate AST to e.g. re-introduce member references.
Resolves: rdar://problem/46497155
Context archetypes and opened existential archetypes differ in a number of details, and this simplifies the overlapping storage of the kind-specific fields. This should be NFC; for now, this doesn't change the interface of ArchetypeType, but should allow some refinements of how the special handling of certain archetypes are handled.
When parameter refers to something undefined its type is going to
be `ErrorType`, so diagnostic path needs to make sure that parameter
has a valid function type before trying to extract result from it.
Resolves: rdar://problem/46377919
In #7530, NominalTypeDecl::lookupDirect() started returning TinyPtrVector instead of ArrayRef so that it wouldn’t be returning a pointer into a mutable data structure. Unfortunately, some callees assigned its return value into an ArrayRef; C++ happily converted the TinyPtrVector to an ArrayRef and then treated the TinyPtrVector as out-of-scope, so the ArrayRef would now point to an out-of-scope object. Oops.
* Implement dynamically callable types (`@dynamicCallable`).
- Implement dynamically callable types as proposed in SE-0216.
- Dynamic calls are resolved based on call-site syntax.
- Use the `withArguments:` method if it's defined and there are no
keyword arguments.
- Otherwise, use the `withKeywordArguments:` method.
- Support multiple `dynamicallyCall` methods.
- This enables two scenarios:
- Overloaded `dynamicallyCall` methods on a single
`@dynamicCallable` type.
- Multiple `dynamicallyCall` methods from a `@dynamicCallable`
superclass or from `@dynamicCallable` protocols.
- Add `DynamicCallableApplicableFunction` constraint. This, used with
an overload set, is necessary to support multiple `dynamicallyCall`
methods.
Let's keep track of type mismatch between type deduced
for the body of the closure vs. what is requested
contextually, it makes it much easier to diagnose
problems like:
```swift
func foo(_: () -> Int) {}
foo { "hello" }
```
Because we can pin-point problematic area of the source
when the rest of the system is consistent.
Resolves: rdar://problem/40537960
If failed constraint mentions member declaration which is not
generic, it means that generic requirements came from context
and should not be diagnosed by `diagnoseUnresolvedDotExprTypeRequirementFailure`.
Resolved: rdar://problem/45511837
Arbitrary currying is no longer allowed so level could be switched
to a boolean flag for methods like `computeDefaultMap` to identify
if they need to look through curried self type or not.
Forming constraints instead of using `matchTypes` while matching argument/parameter
types makes sure that `failedConstraint` points to failed argument conversion
instead of `applicable function` constraint, which is better for diagnostics.
There's no need to instantiate archetypes in the generic environment
of the declaration being opened.
A couple of diagnostics changed. They were already misleading, and the
new diagnostics, while different, are not any more misleading than
before.
`\.self` is the final chosen syntax. Implement support for this syntax, and remove the stopgap builtin and `WritableKeyPath._identity` property that were in place before.
Previously we would generate the following constraint here, where
'index' and 'output' are concrete types and $input is a type
variable:
- ValueMember(base, $input -> output)
- ArgumentTupleConversion(index, $input)
The problem is that we built a function type where the entire input
was a type variable, which would then bind to an argument list.
We could instead generate this constraint:
- ValueMember(base, $member)
- ApplicableFunction(index -> output, $member)
I also had to redo how keypaths map locators back to key path
components. Previously the ArgumentTupleConversion was created
with a locator ending in KeyPathComponent.
Now the ApplicableFunction is created with this locator, which means
the argument match is performed with a locator ending in
ApplyArgument.
A consequence of this is that the SubscriptIndex and SubscriptResult
locator path elements are no longer used, so remove them.
This requires various mechanical changes in places we look at
locators to handle this change. Should be NFC.
We were building the following constraint, where $member and
$input are type variables and 'result' is a concrete type:
- Conversion($member, $input -> result)
When $member was fixed to a function type of arbitrary
arity, this would simplify to a conversion between $member's
result type and 'result'.
Instead, express this using the newly-added FunctionResult
constraint:
- FunctionResult($member, $result)
- Conversion($result, result)
I wasn't expecting this to change diagnostics, but it looks
like it did; I'm not going to bother investigating why,
because Pavel is going to rewrite contextual diagnostics soon
anyway. All but one are clear improvements.
Fixes <rdar://41416346> and <rdar://41416647>, two cases where
diagnostics regressed from -swift-version 3 to -swift-version 4.
Previously we would generate the following constraints here, where
'base', 'arg' and 'result' are concrete types, and $t is a type
variable:
- ValueMember(base, $t -> result)
- ArgumentTupleConversion(arg, $t)
Instead, we now generate these constraints:
- ValueMember(base, $method)
- ApplicableFunction(arg -> result, $method)
Recall that when the right hand side of an ApplicableFunction is
fixed, it simplifies down to an ArgumentTupleConversion and a
Bind. So the above formulation is equivalent, except that again,
we avoid forming a FunctionType where the entire input type is
a single type variable.
As with the UnresolvedDotExpr case, the old code set the
TVO_PreferSubtypeBinding flag on $t, so to preserve the old
ranking behavior, we generate an additional type variable and
constraint:
- FunctionInput($method, $arg)
This is just a temporary stop-gap until TVO_PreferSubtypeBinding
is removed.
Note that if the arguments to a constructor call are invalid, we
now fail the ApplicableFunction constraint and not a
ArgumentTupleConversion. This requires a minor change in CSDiag.
The whole concept of looking at the failed constraint is going
away hopefully, in favor of more precise TypeMatchResult and
Fix-based logic.
Merge logic from `diagnoseAssignmentFailure` and `diagnoseSubElementFailure`
into new `AssignmentFailure`, together with their support functions, which
decouples `CSDiagnostics` from `CSDiag` and scrubs latter from some functionality.
