Further simplify `addOverloadSet` and move "outer" candidate handling
to the only place where it comes up - `simplifyMemberConstraint`.
Also move constraint generation for choices into a separate method.
This is a stepping stone on the path to enable attaching fixes to
the overload choices.
- Remove whole disjunction favoring which has no effect;
- Avoid creating separate disjunction for "inner" choices,
which is going to be flattened later anyway.
When we’re trying to find the overload set corresponding to a particular
type variable, look through “optional object of” constraints that represent
the use of ? binding or ! forcing. This allows us to find overload sets
when referring to, e.g., @objc optional protocol requirements.
This narrow favoring rule makes more sense as part of disjunction
partitioning, because it is not dependent on the use site at all and
should only kick in when other options fail.
The "common type" optimization isn't really buying us anything at this
point, because we're not able to make much use of the common structure
often enough. Revert the "common type" optimization for now... I'll
bring it back when there's enough optimization infrastructure around
it to make it compelling.
The walker that was setting argument labels was looking through ! and ?
postfix expressions, but the lookup code itself was not, leading to missed
opportunities for filtering based on argument labels. Generalize the
transformation that maps from the function expression down to the locator
for which we will retrieve argument labels.
When simplifying a function application constraint, check the argument
labels for that application against the disjunction containing the overload
set, disabling any overloads with mis-matching labels. This is staging for
several different directions:
* Eliminating the argument label matching from performMemberLookup, where it
does not belong
* More aggressively filtering the overload set when we have some concrete
information about argument types
* Identifying favored constraints when we have some concrete information
about argument types
At present, the only easily-visible effect of this change is that
we now properly handle argument label matching for non-member functions.
Constraint generation for function application expressions contains a simple
hack to try to find the common result type for an overload set containing
callable things. Instead, perform this “common result type” computation
when simplifying an applicable function constraint, so it is more
widely applicable.
Given an overload set, attempt to compute a "common type" that
abstracts over all entries in the overload set, providing more
structure for the constraint solver.
Extend existing `RequirementFailure` functionality to support
conditional requirement failures. Such fixes are introduced
only if the parent type requirement has been matched successfully.
Resolves: rdar://problem/47871590
Instead of storing information about expression depths in the
solver state (which gets recomputed for salvage) let's track
it directly in constraint system, which also gives solver
access to it when needed e.g. for fixes.
This helps to postpone attempting bindings related to generic
parameters with all else being equal.
Consider situation when function has class requirement on its
generic parameter. Without such requirement solver would infer
sub-class for `T`. But currently when requirement is present base
class is inferred instead, because when bindings for such generic
parameter are attempted early single available binding at that
point comes from the requirement.
```swift
class BaseClass {}
class SubClass: BaseClass {}
struct Box<T> { init(_: T.Type) {} }
func test<T: BaseClass>(box: Box<T>) -> T.Type {
return T.self
}
test(box: .init(SubClass.self)) // `T` expected to be `SubClass`
```
Resolves: [SR-9626](https://bugs.swift.org/browse/SR-9626)
Resolves: rdar://problem/47324309
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
If lookup couldn't find anything matching given name, let's try to
fake its presence based on how member is being used. This is going
to help (potentially) type-check whole expression and diagnose the
problem precisely.
Removes the _getBuiltinLogicValue intrinsic in favor of an open-coded
struct_extract in SIL. This removes Sema's last non-literal use of builtin
integer types and unblocks a bunch of cleanup.
This patch would be NFC, but it improves line information for conditional expression codegen.
The new SIMD proposal introduced a number of new operators, the presence of
which causes more "expression too complex" failures. Route around the
problem by de-prioritizing those operators, visiting them only if no
other operator could be chosen. This should limit the type checker
performance cost of said operators to only those expressions that need
them OR that already failed to type-check.
Fixes rdar://problem/46541800.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
In postfix completion, for operator completion, we do:
1. Type check the operand without applying it, but set the resolved
type to the root of the expression.
2. For each possible operators:
i. Build temporary binary/postfix expression
ii. Perform type checking to see whether the operator is applicable
This could be very slow especially if the operand is complex.
* Introduce `ReusePrecheckedType` option to constraint system. With
this option, CSGen respects pre-stored types in expressions and doesn't
take its sub-expressions into account.
* Improve type checking performance because type variables aren't
generated for sub-expressions of LHS (45511835)
* Guarantee that the operand is not modified by the type checker because
expression walkers in `CSGen` doesn't walk into the operand.
* Introduce `TypeChecker::findLHS()` to find LHS for a infix operator from
pre-folded expression. We used to `foldSequence()` temporary
`SequenceExpr` and find 'CodeCompletionExpr' for each attempt.
* No need to flatten folded expression after initial type-checking.
* Save memory of temporary `BinaryExpr` which used to be allocated by
`foldSequence()`.
* Improve accuracy of the completion. `foldSequence()` recovers invalid
combination of operators by `left` associative manner (with
diagnostics). This used to cause false-positive results. For instance,
`a == b <HERE>` used to suggest `==` operator. `findLHS()` returns
`nullptr` for such invalid combination.
rdar://problem/45511835
https://bugs.swift.org/browse/SR-9061
Currently logic in `matchCallArguments` could only detect argument
being an @autoclosure parameter for normal calls and operators.
This patch extends it to support subscripts and unresolved member calls.
- Use `int` instead of `unsigned int` to represent # of non-defaultable bindings.
Because the formula is `-(Total - Defaultable)` which could only be `0` or negative.
- Increase number of defaultable bindings iff the binding is accepted.
* Gardening for `@dynamicMemberLookup`.
- Unify code style of `@dynamicMemberLookup` and `@dynamicCallable` implementations.
- Use consistent variable names, diagnostic messages, doc comments, etc.
- Move `@dynamicMemberLookup` test to `test/attr` directory.
When `bind param` constraint is associated with a given
type variable a set of bindings collected for it is
potentially incomplete, because binding gathering doesn't
look through related type variables. Which means that
such type variable has to be de-prioritized until
`bind param` constraint is resolved or there is just
nothing else to try, otherwise there is a risk that
solver would skip some of the valid solutions.
This only affects type variable that appears one the
right-hand side of the `bind param` constraint and
represents result type of the closure body, because
left-hand side gets types from overload choices.
Resolves: rdar://problem/45659733
* 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.
When `bind param` constraint is associated with a given type
variable a set of bindings collected for it is potentially
incomplete, because binding gathering doesn't look through related
type variables. Which means that such type variable has to be
de-prioritized until `bind param` constraint is resolved
or there is just nothing else to try, otherwise there is a
risk that solver would skip some of the valid solutions.
Resolves: rdar://problem/45659733
In cases where we have multiple designated types, sort the types that
were designated for this operator based on any information we can
gather about actual argument types at usage sites.
We can consider extending this further in a future commit to ignore
designated types when we have concrete type information that we are
confident of.
