* 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
Since 'try?' no longer unconditionally adds a layer of optional, converting it
to 'try!' will no longer unconditionally remove a layer of optional. So let's not
suggest it. This leads to better diagnostics anyway.
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.
It was useful when logic related to `BridgingConstraint` was part of
`Conversion` constraint, which could be generated as a result of implicit
conversion for an operator parameter.
There are cases when adding missing conformance fix doesn't really
make sense like in case of `Void` and `Never` types because that
wouldn't result in a useful diagnostic.
This is a follow-up for rdar://problem/44770297
`\.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.
This silences the instances of the warning from Visual Studio about not all
codepaths returning a value. This makes the output more readable and less
likely to lose useful warnings. NFC.
It should be a no-op to remove it entirely but it has an effect
on ranking I don't understand. Refactor it in preparation for
changing matchCallArguments() to work on parameter lists instead
of types.
Even if the RHS is 'Any', we don't want to solve the constraint if
'LHS' is a type variable, because the type variable might be bound
to a noescape function type later.
Noticed by inspection and I don't have a test case; it may well
be NFC because of how CSBindings works.
Now that function types cannot have a naked type variable as
their input type it's no longer possible to have an unsolved
ArgumentTupleConversion constraint, so we can bypass most of
the logic in matchTypes() and call matchCallArguments() instead.
Now that function types cannot have a naked type variable as
their input type we should never end up down this code path
with an associated declaration and argument labels, so it's
OK to just call matchTypes() on the input types instead.
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.
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.
These are temporary.
FunctionInput is conditional on fixing some ranking behavior to not
depend on type variables having argument tuples bound to them.
Hopefully we can replace TVO_PreferSubtypeBinding with a better
mechanism that compares overload types instead.
FunctionResult is used in CSDiag's contextual type diagnostics.
This is also on the chopping block.
Since `ConstraintFix` references `ConstraintSystem` directly now,
we can get `SourceManager` from `ASTContext` associated with that
`ConstraintSystem` instead of passing it in every time.
Avoid claiming un-labeled defaulted parameters
by out-of-order un-labeled arguments or parts
of variadic argument sequence, because that might
be incorrect.
The following example is supposed to type-check
correctly but without these changes produces
`missing argument for parameter #4 in call`
error, because `3` will be claimed as '_ b:':
```swift
func foo(_ a: Int, _ b: Int = 0, c: Int = 0, _ d: Int) {}
foo(1, c: 2, 3)
```
Resolves: rdar://problem/43525641
This makes it easier to grep for and eventually remove the
remaining usages.
It also allows you to write FunctionType::get({}, ...) to call the
ArrayRef overload empty parameter list, instead of picking the Type
overload and calling it with an empty Type() value.
While I"m at it, in a few places instead of renaming just clean up
usages where it was completely mechanical to do so.
- getAsDeclOrDeclExtensionContext -> getAsDecl
This is basically the same as a dyn_cast, so it should use a 'getAs'
name like TypeBase does.
- getAsNominalTypeOrNominalTypeExtensionContext -> getSelfNominalTypeDecl
- getAsClassOrClassExtensionContext -> getSelfClassDecl
- getAsEnumOrEnumExtensionContext -> getSelfEnumDecl
- getAsStructOrStructExtensionContext -> getSelfStructDecl
- getAsProtocolOrProtocolExtensionContext -> getSelfProtocolDecl
- getAsTypeOrTypeExtensionContext -> getSelfTypeDecl (private)
These do /not/ return some form of 'this'; instead, they get the
extended types when 'this' is an extension. They started off life with
'is' names, which makes sense, but changed to this at some point. The
names I went with match up with getSelfInterfaceType and
getSelfTypeInContext, even though strictly speaking they're closer to
what getDeclaredInterfaceType does. But it didn't seem right to claim
that an extension "declares" the ClassDecl here.
- getAsProtocolExtensionContext -> getExtendedProtocolDecl
Like the above, this didn't return the ExtensionDecl; it returned its
extended type.
This entire commit is a mechanical change: find-and-replace, followed
by manual reformatted but no code changes.
`Fix` life-time is pretty limited as it is, and we'd have
to distinguish between standalone fixes and ones attached
to constraints, which is not worth the trouble.
Resolves: rdar://problem/43285774
