Instead of passing all of the information available in the diagnostic
to static functions, let's bring "default value" and "force unwrap"
fix-it logic under "missing optional unwrap diagnostic" umbrella.
This PR migrates instance member on type and type member on instance diagnostics handling to use the new diagnostics framework (fixes) and create more reliable and accurate diagnostics in such scenarios.
Previously the logic to determine path to the selected overload
in such case was simplistic and only checked the name to be
of constructor, but `ConstructorMember` path is formed only if
member reference is a constructor delegation e.g. `self.init` or
`super.init` in an initializer context.
Detect that failed requirement comes from contextual type and use
that information to determine affected declaration.
Resolves: rdar://problem/47980354
For context, String, Nil, and Bool already behave this way.
Note: Before it used to construct (call, ... (integer_literal)), and the
call would be made explicit / implicit based on if you did eg: Int(3) or
just 3. This however did not translate to the new world so this PR adds
a IsExplicitConversion bit to NumberLiteralExpr. Some side results of
all this are that some warnings changed a little and some instructions are
emitted in a different order.
If affected declaration is a static or instance memeber (excluding
operators) and failed requirement is declared in other nominal type
or extension, diagnose such problems as `in reference` instead of
claiming that requirement belongs to the member itself.
Situations like:
```swift
struct S {}
func foo(_ s: S.Type) {
_ = s()
}
```
Used to be diagnosed in solution application phase, which means that
solver was allowed to formed an incorrect solution.
- Attempting to construct class object using metatype value via
non-required initializer
- Referencing initializer of protocol metatype base
Both of the diagnostics are used by `AllowInvalidInitRef` fix.
* 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
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
Since the rule is to prioritize names over types, let's diagnose
ambiguous solutions containing subscript operator fix as missing
member and list possible candidates to use.
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.
Detect and fix situations when (force) unwrap is used on
a non-optional type, this helps to diagnose invalid unwraps
precisely and provide fix-its.
Resolves: [SR-8977](https://bugs.swift.org/browse/SR-8977)
Resolves: rdar://problem/45218255
Fuzzing found a problem related to re-typecheck introducing
`MemeberRefExpr` into AST with failing requirements which
are then diagnosted via fixes, quite unlikely case to be
found in the wild.
Suggest to add `()` (form a call) to correctly forward argument function
originated from `@autoclosure` parameter to function parameter itself
marked as `@autoclosure`.
* 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.
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.
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.
