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
Currently invalid initializer references are detected and
diagnosed in solution application phase, but that's too
late because solver wouldn't have required information while
attempting to determine the best solution, which might result
in viable solutions being ignored in favour of incorrect ones e.g.
```swift
protocol P {
init(value: Int)
}
class C {
init(value: Int, _: String = "") {}
}
func make<T: P & C>(type: T.Type) -> T {
return T.init(value: 0)
}
```
In this example `init` on `C` would be preferred since it
comes from the concrete type, but reference itself is invalid
because it's an attempt to construct class object using
metatype value via non-required initalizer.
Situations like these should be recognized early and invalid
use like in case of `C.init` should be ranked lower or diagnosed
if that is the only possible solution.
Resolves: rdar://problem/47787705
* Make sure that base and unwrapped types aren't null
* Don't allocate `ForceOptional` fix if nothing has been unwrapped
in `simplifyApplicableFnConstraint`
* Add sugar reconstitution support to `FailureDiagnostic::resolveType`
* Format diagnostics a bit better
Solving Bind is a little easier than Equal. The only remaining uses of Equal
are in the .member syntax and keypaths; if we can refactor those, we might be
able to simplify LValue handling in the type checker in general.
- Avoid creating an unnecessary type variable
- Even if both sides are type variables we can solve them if the LHS cannot
bind to an InOut or the RHS cannot bind to an LValue; in this case the two
types are identical and we can merge them
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.
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.
If the base type is not optional, trying to unwrap it is
incorrect. Introduce a fix to make it look like base was
an optional type which leads solver to move forward
towards possible solution.
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
While matching two metatypes where one side is a class (which could have
supertypes) and another is a type variable use `subtype` constraint to
delay binding types together because there is a real possibility that
there exists a superclass associated with yet free type variable which
would be a better match when attempted.
Resolves: rdar://problem/44816848
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.
This allows us to skip attempting actual conversions.
This speeds up one of our slow test cases, and perturbs the output of
another test. In the latter case, we stop emitting conversions as part
of the non-semantic piece of the array_expr. The fact that we're not
putting conversions in on that path is something I've seen before in
other instances. I'll open a bug if I cannot find one for it, although
I believe it's entirely cosmetic in this case since we don't rely on
the conversion being there.
- Enable `subscript(dynamicMember:)` as a requirement for
`@dynamicMemberLookup` protocols.
- Add tests.
- Minor `@dynamicCallable`-related gardening.
Resolves SR-8077.
* 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.
Make sure that presence of `@autoclosure` attribute handled
in one place - `matchCallArguments`, which makes it possible
to remove the rest of (now redundant) autoclosure related
logic scattered throughout solver.
* 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.
