A key path component that resolved to an `ErrorExpr` would be diagnosed twice: once when the `ErrorExpr` was created, then again when it was processed. Fix this redundant diagnostic.
The changes from https://github.com/swiftlang/swift/pull/84259/ caused a
regression in which declarations from an outer scope could be shadowed
inappropriately by member declarations from a module that has not been
imported. This fix addresses the issue by refactoring `resolveDeclRefExpr()` so
that it performs lookups in two passes. First, it attempts to resolve the decl
ref using the complete lookup algorithm and standard name lookup options, which
will ignore members from modules that haven't been imported if
`MemberImportVisibility` is enabled. Then, if no results were found it re-runs
the full lookup algorithm again with `NameLookupFlags::IgnoreMissingImports`
included to find additional results that ought to be diagnosed as unavailable.
This insures that the unavailable results are not considered until after the
main lookup has already failed.
Resolves rdar://161078015.
`TypeChecker::resolveDeclRefExpr()` would leave error nodes in the AST when
performing fallback name lookups with `MemberImportVisibility`. When running in
migration mode for `MemberImportVisibility`, these error nodes would then cause
the compiler to either diagnose a missing error or to crash during SILGen.
Instead of restricting name lookup during `TypeChecker::resolveDeclRefExpr()`,
allow it to find candidates with missing imports and then diagnose them if
necessary before forming a resolve decl ref.
Resolves rdar://154361861.
This is useful for ArrowExpr when the sub-expressions aren't valid
TypeExprs. Rather than throwing away the AST, attach it to the
ErrorTypeRepr to ensure we can still type-check it. This ensures
semantic functionality still works correctly, and fixes a crash where
we'd stop visiting an invalid binding pattern, losing track of the
nested VarDecl.
We set an original expression on ErrorExpr for cases where we have
something semantically invalid that doesn't fit into the AST, but is
still something that the user has explicitly written. For example
this is how we represent unresolved dots without member names (`x.`).
We still want to type-check the underlying expression though since
it can provide useful diagnostics and allows semantic functionality
such as completion and cursor info to work correctly.
rdar://130771574
Sema seems to be flagging inout expressions (e.g. &foo) in expression
macros as invalid, setting up a catch 22 where Sema emits an error when
a parameter has the '&' sigil and type checking fails when it doesn't.
This resolves the issue by allowing inout expressions inside macro
expansion expressions.
Resolves https://github.com/swiftlang/swift/issues/82369.
Postfix operators can further be chained within an optional binding
chain, so we need to make sure they're handled in
`getMemberChainSubExpr`. Unresolved member chains still don't allow
them, so we need to add a new `kind` parameter to differentiate the
behavior here.
rdar://147826988
Expand the special-cased ASTWalker behavior for folded SequenceExprs
such that we always walk the folded expression when available. This
ensures that we don't attempt to add the same node multiple times
when expanding ASTScopes during pre-checking.
rdar://147751795
Since availability scopes may be built at arbitrary times, the builder may
encounter ASTs where SequenceExprs still exist and have not been folded, or it
may encounter folded SequenceExprs that have not been removed from the AST.
To avoid a double visit, track whether a SequenceExpr is folded and then
customize how ASTVisitor handles folded sequences.
Resolves rdar://142824799 and https://github.com/swiftlang/swift/issues/78567.
FunctionRefKind was originally designed to represent
the handling needed for argument labels on function
references, in which the unapplied and compound cases
are effectively the same. However it has since been
adopted in a bunch of other places where the
spelling of the function reference is entirely
orthogonal to the application level.
Split out the application level from the
"is compound" bit. Should be NFC. I've left some
FIXMEs for non-NFC changes that I'll address in a
follow-up.
