Like every other method entry in the default witness table, the default
implementations of the `read2` and `modify2` accessors that just call
`read` and `modify` respectively should be transparent.
Introduce `getKeyPathTypeForDynamicMemberLookup`
which returns the KeyPath type, and can be used
from both `RootAndResultTypeOfKeypathDynamicMemberRequest`
and `isValidKeyPathDynamicMemberLookup`. This ensures
we look to the superclass for e.g protocol compositions
with `Sendable`. This also means we now return an
interface type, which is what the client of
`RootAndResultTypeOfKeypathDynamicMemberRequest`
wanted anyway.
rdar://138418296
Rather than exposing an `addFile` member on
ModuleDecl, have the `create` members take a
lambda that populates the files for the module.
Once module construction has finished, the files
are immutable.
If the base type of the specialization is invalid,
the AST node is going to be replaced with `ErrorExpr`.
We need to handle that gracefully when attempting
to apply specialization in such situations.
Resolves: https://github.com/swiftlang/swift/issues/77644
Introduce a number of fixes to allow us to fully use declarations that
are produced by applying a peer macro to an imported declarations.
These changes include:
* Ensuring that we have the right set of imports in the source file
containing the macro expansion, because it depends only on the module
it comes from
* Ensuring that name lookup looks in that file even when the
DeclContext hierarchy doesn't contain the source file (because it's
based on the Clang module structure)
Expand testing to be sure that we're getting the right calls,
diagnostics, and generated IR symbols.
Situations like:
```
let _: Double = <<CGFloat>>
<var/property of type Double> = <<CGFloat>>
```
Used to be supported due to an incorrect fix added in
diagnostic mode. Lower impact here means that right-hand
side of the assignment is allowed to maintain CGFloat
until the very end which minimizes the number of conversions
used and keeps literals as Double when possible.
Resolves: rdar://139675914
Previously we would check if we have a SwitchStmt,
and apply diagnostics such as `checkExistentialTypes`
to the CaseStmts individually. This however would
have been missed for `catch` statements. The change
to consistently call `performStmtDiagnostics` in
closures fixed this for `do-catch`'s in closures,
this commit fixes it for those outside of closures.
Because this is source breaking, the existential
diagnostic is downgraded to a warning until Swift
7 for catch statements specifically.
While here, also apply the ambiguous where clause
diagnostic to `catch` statements.
Simplifies things a tiny amount, and ensures we
don't attempt to walk into non-PatternBindingDecls,
same as other MiscDiagnostic passes. I don't think
this currently makes a difference since I don't
believe we have any interesting cases where a Decl
is nested in an Expr without an intermediate Stmt,
but it's the right thing to do regardless.
The walker here is really doing 2 completely
separate things, split it into 2 walkers. For
ExprAvailabilityWalker, we just want to recursively
continue walking looking for any sub-expressions
to diagnose. For StmtAvailabilityWalker we only
want to walk the top-level statement, and are
only interested in any TypeReprs it has. This lets
us get rid of the special handling for BraceStmt.
Instead, ensure we walk into expressions in
SyntacticDiagnosticWalker, allowing
`performStmtDiagnostics` to be called there for
all statements present in the target. This avoids
a case where we'd double diagnose.
While here, inherit the walker from
BaseDiagnosticWalker.
