If return of optional chaining is assigned to an optional type
or discarded there should be no force optional unwrap attempt
on it because type variable associated with context can be
bound to optional of any depth.
Resolves: rdar://problem/57668873
Pull these calls out of lookup itself to prevent re-entrancy. Synthesizing these members can force a conformance check that can ultimately wind up back in lookup. Pull the forcing out of every single qualified lookup and just install these members in the TypeChecker's entrypoints to lookup.
The upside is we can localize this gross hack, the downside is, of course, that we have to smear it across all of the lookup entrypoints.
Force this check to occur so that the interface types of members can successfully make reference to CodingKeys. This is an egregious emergent behavior of Codable that currently forces two protocol conformance checks just to synthesize a type witness. We can definitely get away with just creating the witness up front.
rdar://56844567
Apply the same checks as ApplyExprs to
UnresolvedMemberExprs in getCalleeLocator to
resolve callees in cases where they're used with
`callAsFunction` in addition to a weird edge case
where we currently allow them with constructor
calls, e.g:
```
struct S {
static let s = S.self
}
let x: S = .s()
```
Arguably we should be representing ".member()"
expressions with an UnresolvedMemberExpr + CallExpr,
which would avoid the need to apply these special
cases, and reject the above syntax for not using
an explicit ".init". Doing so will likely require
a bit of hacking in CSGen though.
Resolves SR-11909.
With the new way of caching overloads in the
constraint system, we no longer allow different
overloads to be resolved for the same locator in
the same scope.
Adjust the property wrapper logic
so that it appends Member locator elements for
nested lookups.
Rather than maintaining a linked list of overload
choices, which must be linearly searched each time
we need to lookup an overload at a given callee
locator, use a MapVector which can be rolled back
at the end of a scope.
Remove ResolvedOverloadSetListItem in favor of
using SelectedOverload, which avoids the need to
convert between them when moving from
ConstraintSystem to Solution.
It's possible to construct subscript member responsible for key path
dynamic member lookup in a way which is going to be self-recursive
and an attempt to lookup any non-existent member is going to trigger
infine recursion.
Let's guard against that by making sure that the base type of the
member lookup is different from root type of the key path.
Resolves: rdar://problem/50420029
Resolves: rdar://problem/57410798
Swift classes cannot meaningfully conform to NSObjectProtocol.
Inheriting from NSObject is the appropriate fix, so suggest that.
Fixes rdar://problem/32543753.
If return type is a function, it's possible to return a closure
which can have some of its arguments unused in the body e.g.
`let _: () -> ((Int) -> Void) = { return { } }`
In this case resulting closure has to use its only parameter or
explictly ignore it by declaring `_ in`.
Previously we were just searching for a resolved
overload with the same component index and anchor
for the key path. However unfortunately that found
dynamic member lookup overloads in certain cases,
leading to an incorrect mutability capability.
Change the logic such that it uses the callee
locator for a given key path component, ensuring
we only match against the "direct" callee, and
not any dynamic members it might be also referring
to.
Resolves SR-11896.
Previously we missed caching component types in
one case, and cached the wrong type in another.
Make both cases use cacheExprTypes to cache the
correct component types.
Previously we were only handling IUO unwrapping in
visitKeyPathExpr, but not for callers that were
building their own property and subscript
components such as dynamic member lookup.
Move the IUO unwrapping logic into
buildKeyPath[Property/Subscript]Component,
and adjust their signatures to allow them to
append multiple components. Also add
buildKeyPathOptionalForceComponent to allow more
convenient adding of an optional force component.
Resolves SR-11893.
Rather than setting `baseTy` for each component,
just set it for the last component in the
iteration. In addition, remove the `component`
variable, which no longer serves a purpose.
Finally, cache all the component types at the end
of the loop.
When originally implemented (a5ca6ccd61),
we used to append the set `component` to
`resolvedComponents`, however that appears to have
been refactored away at some point, leaving a couple
of dead assignments. Restore the old behaviour by
just appending the components.
Previously, property names are hidden in the whole range of the
declarations. Now, it's only hidden in its own initializer range.
rdar://problem/49697202
We've changed *what* is serialized by changing the way
@_dynamicReplacement is type checked, but not *how* it's
serialized. Bump the format so there aren't strange incompatibilities
because of this.
Complete the refactoring by splitting the semantic callers for the original decl of a dynamically replaced declaration.
There's also a change to the way this attribute is validated and placed. The old model visited the attribute on any functions and variable declarations it encountered in the primary. Once there, it would strip the attribute off of variables and attach the corresponding attribute to each parsed accessor, then perform some additional ObjC-related validation.
The new approach instead leaves the attribute alone. The request exists specifically to perform the lookups and type matching required to find replaced decls, and the attribute visitor no longer needs to worry about revisiting decls it has just grafted attributes onto. This also means that a bunch of parts of IRGen and SILGen that needed to fan out to the accessors to ask for the @_dynamicReplacement attribute to undo the work the type checker had done can just look at the storage itself. Further, syntactic requests for the attribute will now consistently succeed, where before they would fail dependending on whether or not the type checker had run - which was generally not an issue by the time we hit SIL.
Add DynamicallyReplacedDeclRequest to ValueDecl and plumb the request through to TypeCheckAttr where it replaces TypeChecker::findReplacedDynamicFunction.
