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.
I missed this in my previous PR, but this is needed
to ensure we visit macro arguments for macro expansion
exprs that have substitute MacroExpansionDecls since
we prefer to visit the arguments on the decl once
the expression has been expanded.
Importing a clang submodule from Swift implies importing the top-level
module too. We make sure we don't warn on the import of the top-level
module as being unused when the submodule is used by associating all
references to the top-level module instead of submodules. This change
applies the same logic for transitive imports, marking the import of the
top-level module as used instead of the submodule with the `export *`.
In the updated test, this silences the following warning:
```
public import of 'ClangReexportedSubmodulePublic' was not used in public
declarations or inlinable code
```
rdar://139492772
While private and protected fields coming from C++ cannot be accessed from Swift, they can affect Swift typechecking.
For instance, the Swift typechecker mechanism that adds implicit `Sendable` conformances works by iterating over all of the struct's fields and checking whether all of them are `Sendable`. This logic was broken for C++ types with private fields, since they were never accounted for. This resulted in erroneous implicit `Sendable` confromances being added.
Same applies for `BitwiseCopyable`.
In addition to this, ClangImporter used to mistakenly mark all C++ structs that have private fields as types with unreferenceable storage, which hampered optimizations.
As a side effect of this change, we now also provide a better diagnostic when someone tries to access a private C++ field from Swift.
rdar://134430857
While Span is present, we don't yet have an official way to create Span
instances. Until then, put uses of Span and RawSpan behind an
experimental feature flag (`Span`) that must be set to use these.
Addresses rdar://139308307.
Local functions can capture variables from parent
closures, so we need to make sure we type-check
parent closures when doing completion in a local
function. Ideally we ought to be able to be more
selective about the elements of the parent closure
that we type-check, but that's a more complex change
I'm leaving as future work for now.
Really this applies to any capture, not just
`self`. Also refactor to make it clear that
parent closures and functions are really the only
cases that matter here.
Previously we would only run MiscDiagnostics
passes on macro arguments for some statement
diagnostics, update the expression walkers that
inherit from BaseDiagnosticWalker such that we
consistently do MiscDiagnostics on macro arguments.
