Semantically, the capture list binding behavior doesn't require the scope
to be an explicit closure, and forming new ClosureExprs during type-checking
is difficult because they have to have preassigned discriminators, unlike
AutoClosureExprs which get discriminators introduced by Sema itself. Allowing
CaptureListExpr to hold an AutoClosureExpr makes it easier to synthesize
CaptureListExprs during type checking, to represent expressions with closure
semantics that evaluate some parts of the expression eagerly in the surrounding
context.
Replace the use of bool and pointer returns for
`walkToXXXPre`/`walkToXXXPost`, and instead use
explicit actions such as `Action::Continue(E)`,
`Action::SkipChildren(E)`, and `Action::Stop()`.
There are also conditional variants, e.g
`Action::SkipChildrenIf`, `Action::VisitChildrenIf`,
and `Action::StopIf`.
There is still more work that can be done here, in
particular:
- SourceEntityWalker still needs to be migrated.
- Some uses of `return false` in pre-visitation
methods can likely now be replaced by
`Action::Stop`.
- We still use bool and pointer returns internally
within the ASTWalker traversal, which could likely
be improved.
But I'm leaving those as future work for now as
this patch is already large enough.
Turns out we were getting away with dereferencing
`nullptr` in a few cases as `walk` would use
`nullptr` to indicate that the walk should be
stopped, and luckily Clang didn't optimize it to
something broken.
This commit is fairly defensive and sprinkles
some null checks for calls to `walk` directly
on a body of a function or top-level code decl.
When we get rid of `LeaveClosureBodiesUnchecked` we no longer save closure types to the AST and thus also don’t save their actor isolation to the AST. Hence, we need to extract types and actor isolations of parent closures from the constraint system solution instead of the AST. This prepares `ActorIsolationChecker` to take custom functions to determine the type of an expression or the actor isolation of a closure.
When a value is initialized or coerced for a type that conforms to
one of the `ExpressibleBy*Literal` protocols (or
`ExpressibleByStringInterpolation`), this change records an implicit
call to the corresponding `init(...Literal:)` in the indexstore,
located at the beginning of the literal.
`typealias` is currently allowed to refer to a protocol without the `any` keyword. This breaks mangling the typealias type into a USR will crash because parameterized protocols are expected to be `any` types.
Implement a SourceKit-specific minimal workaround for that problem by not computing USRs for parameterized protocols.
rdar://98623438
apple/swift#60716 changed `NominalTypeDecl::getAllProtocols` to no longer work on `ProtocolDecl`. Add a new wrapper to Refactoring.cpp that dispatches to either `getInheritedProtocols` or `getAllProtocols` depending on whether the type is a protocol or not.
rdar://99096663
When an function has an async alternative, that should be preferred when we are completing in an async context. Thus, the sync method should be marked as not recommended if the current context can handle async methods.
rdar://88354910
Store whether a result is async in the `ContextFreeCodeCompletionResult` and determine whether an async method is used in a sync context when promoting the context free result to a contextual result.
rdar://78317170
Cursor info on a reference to a decl that shadows other decls should not
include those decls in the secondary symbols. They should only be
added on the decl itself, if that particular location is *also* the
reference to the shadowed decl (eg. in a shorthand if let or closure
capture).
Resolves rdar://96305891.
Generating diagnostics for "not recommended" items requires an
associated declaration. However, cases like this:
func test(fn: (Int) async -> Void) {
fn(#^HERE^#)
}
For the function call pattern item, there's no associated decl because
the callee is an expression. Ideally it should emit a diagnostic, but
for now, to avoid the crash, don't emit diagnostics unless the item has
the associated decl.
rdar://95306033
Precedence groups should be suggested only at
* After colon in operator decls
* After 'higherThan:' or 'lowerThan:' in precedence group decls
rdar://76977760
Computing type relations to 'Any' is not very enlightning because everything would be convertible to it. If the contextual type is 'Any', just report all type relations as 'Unknown'.
rdar://64812321
rdar://84684686
* InterfaceGen reports a primary associated type as a reference to the
'associatedtype' declaration
* CursorInfo on a primary associated type returns information of the
'associatedtype' declaration
rdar://93275458
Properties can also be specified in a protocol/overridden by subclasses,
so they should also be classed as "dynamic" in these cases.
Removed receiver USRs when *not* dynamic, since it's not used for
anything in that case and should be equivalent to the container anyway.
Resolves rdar://92882348.
