Diagnose situations where `weak` attribute is used with a non-optional type
in declaration e.g. `weak var x: <Type>`:
```swift
class X {
}
weak var x: X = ...
```
`weak` declaration is required to use an optional type e.g. `X?`.
from missing function call errors in `ContextualFailure`.
It doesn't make sense to diagnose pattern matching errors inside of
`diagnoseMissingFunctionCall`, and the code I added to bail out if there
is no explicit function expression broke the pattern matching diagnostics
anyway.
- Explicitly limit favoring logic to only handle
unary args, this seems to have always been the
case, but needs to be handled explicitly now that
argument lists aren't exprs
- Update the ConstraintLocator simplification to
handle argument lists
- Store a mapping of locators to argument lists
in the constraint system
- Abstract more logic into a getArgumentLocator
method which retrieves an argument-to-param locator
from an argument anchor expr
I missed this case when previously improving the
logic here. As it turns out, using the raw anchor
as the root expression from which to derive parent
information is insufficient. This is because it
may not capture relevant parent exprs not a part
of the fix locator.
Instead, pass down a function that can be used to
derive the parent expressions from the constraint
system's own parent map. Also make sure to assign
to `expr` for the UnresolvedMemberChainResultExpr
case to make sure we correctly check for it as a
sub-expression.
Finally, now that we're looking at more parent
exprs, add logic to handle `try` and `await`
parents, as well as ClosureExprs and
CollectionExprs. I couldn't come up with a test
case for CollectionExpr, as we emit different
diagnostics in that case, but it's probably better
to tend on the side of being more future proof
there.
rdar://81512079
For checked cast coercion warnings let's store difference in optionality
as an `int` because it's possible that "to" type is more optional than
"from" type.
We have a couple of reports that `ContextualFailure` crashes in
`trySequenceSubsequenceFixIts` even with the check for a valid
stdlib was added, which can only mean that from/to types are
somehow invalid.
Let's add a couple of asserts to verify their presence to aid us
in determining what expressions can cause the problem.
`ContextualFailure` is the main beneficiary of additional information
associated with `ContextualType` element because it no longer has to
query solution for "purpose" of the contextual information.
Resolves: rdar://68795727
If there is a contextual mismatch associated with a closure body,
make sure that the diagnostic is attached to the closure even
if the body is empty or implicit.
Resolves: rdar://52204608
One can convert from a function value without a global actor to a
similar function type that does have a global actor, but one cannot
remove or change a global actor on a function type.
New name is `isInKeyPathComponent` since it's implemeneted as a
check for presence of `KeyPathComponent` element in the locator
that covers every sub-element contained in a key path component
as well.
* [Sema] Implementing is runtime check always true diagnostic as a fix
* [AST] Implement getWithoutThrows on function type
* [CSSimplify] Detect that checked cast types conversion is always true and record warning fix
* [test] Some additional test cases for SR-13789
* [Sema] Fixing typo on fix name
* [Sema] Move and adjust the ConditionalCast diagnostics to the fix format
* [Sema] Remove some checked cast diagnostics from check constraints and move to fix
* [Sema] Renaming checked cast coercible types fix
* [Sema] Some adjustments and rewrite on the logic for downcast record fix
* [Sema] Move logic of runtime function type to AllowUnsupportedRuntimeCheckedCast::attempt
* [Sema] Abstract checked cast fix logic to static function and minor adjustments
* [Sema] Renamings from review
Introduce `@concurrent` attribute on function types, including:
* Parsing as a type attribute
* (De-/re-/)mangling for concurrent function types
* Implicit conversion from @concurrent to non-@concurrent
- (De-)serialization for concurrent function types
- AST printing and dumping support
In the single-element case, it is treated as the dictionary key.
func takesDict(_ x: [Int: String]) {}
takesDict([]) // diagnose with fixit to add missing ':'
takesDict([1]) // diagnose with fixit to add missing ': <#value#>'
takesDict([foo.<complete>]) // prioritise Int members in completion results -
// the user just hasn't written the value yet.
The above previously failed with a generic mismatch error in normal type
checking (due to the literal being parsed as an array literal) and code
completion could not pick up the expected type from the context.
If AST node is a reference to an invalid declaration let's
diagnose it as such unless some errors have been emitted
(invalid declaration itself should have a diagnostic
describing a reason why it's invalid).
func foo(a: Int, b: Int) {}
func foo(a: String) {}
// Int and String should both be valid, despite the missing argument for the
// first overload since the second arg may just have not been written yet.
foo(a: <complete here>
func bar(a: (Int) -> ()) {}
func bar(a: (String, Int) -> ()) {}
// $0 being of type String should be valid, rather than just Int, since $1 may
// just have not been written yet.
bar { $0.<complete here> }
