Non-‘@objc’ ‘dynamic’ has been allowed since Swift 5, but there’s no
reason to tie it to the language mode (Swift >= 5).
Fixes rdar://problem/50348013.
All places where `invalid member ref` fix/diagnostic is used already
have a reference to the potential member choice declaration, which
diagnostic could take advantage of.
This is useful for `CSDiag` when it detects that all
overload choices have the same problem. Since there
are going to be no solutions, choice declaration could
be supplied to `invalid ref` diagnostic directly.
Resolves: rdar://problem/50467583
Resolves: rdar://problem/50682022
Resolves: rdar://problem/50909555
Originally `filterContextualMemberList` would only return a limited
set of closeness kinds `CC_GeneralMismatch`, `CC_Argument{Label, Count}Mismatch`,
and unavailable/inaccessible. At some point later it also started
matching almost everything besides `CC_SelfMismatch` and logic in
`visitUnresolvedMemberExpr` needs to get adjusted to account for that.
Resolves: rdar://problem/50668864
The walker in SILGenLazyConformance.cpp should be sufficient to catch
any conformances needed at runtime, and after all the recent changes
SILGen is now able to trigger lazy conformance checking and synthesis
of fully-checked function bodies for accessors, which is enough to
remove the explicit conformance checks from Sema in this case.
When a class has missing vtable entries, we don’t allow it to be subclassed. This is unnecessarily restrictive for resilient classes, and @_implementationOnly imports now make missing vtable entries much more common. This commit carves out an exception to that rule for resilient classes.
Fixes <rdar://problem/50902125>.
Extend use of `missing protocol conformance` fix to cover contextual
failures, such as:
- Assignment mismatches, where destination requires source to conform
to certain protocol (or protocol composition);
- Incorrect returns where returned type doesn't conform to the
protocol specified in the signature.
It's okay to have two function parameters with the same external label, as long as the internal labels are different. If not, we already emit a diagnostic for it, so no need to check
The logic I had here checked whether an extension used an
implementation-only type whenever there was a declaration within that
extension that needed checking...but unfortunately that included not
just PatternBindingDecls (whose access is filtered at a later step)
but things like IfConfigDecls (#if). Change this to only check
signatures of extensions with ABI-public members, something that is
tested once when visiting an ExtensionDecl.
Additionally, skip AccessorDecls entirely, since they'll be tested
as part of the corresponding subscript or var. This saves a duplicate
diagnostic.
rdar://problem/50541589
I thought it would be useful to allow some uses of a module to be
'@_implementationOnly' and others to not be in case someone wanted to
change from one to the other gradually, but it turns out that if
you're trying to /make/ an import implementation-only, you want to
know everywhere you used it.
rdar://problem/50748157
Currently we check that the fixes share the same anchor, however this
doesn't account for the case where, given an ApplyExpr, one fix is
anchored on its function expr, and another is anchored on the apply
itself (because the former fix might be looking at the callee's
requirements, and the latter fix might be looking at an argument of
the call).
This commit changes the logic such that we check that fixes share the
same callee locator, which covers the above case. In addition, now
that we have the callee locator, we can use this to find the overload
directly.
This commit adds `ConstraintSystem::getCalleeLocator`, which forms a
locator that describes the callee of a given expression. This function
is then used to replace various places where this logic is duplicated.
This commit also changes the conditions under which a ConstructorMember
callee locator is formed. Previously it was formed for a CallExpr with a
TypeExpr function expr. However, now such a locator is formed if the
function expr is of AnyMetatypeType. This allows it to be more lenient
with invalid code, as well as work with DotSelfExpr.
Resolves SR-10694.
When backward deploying to an OS that may not have these entry points, weak-link them so that they
can be used conditionally in availability contexts that check for them.
rdar://problem/50731151