Sending a `SIGTERM` to sourcekitd XPC service lead to very surprising results: XPC thought that the process was about to die and sends a Connection Interrupted notification to the client. But other than that, we didn’t actually handle the signal and the service stayed alive. This caused us to send a `sema_disabled` notification to the client but since the service never got relaunched, we never sent the corresponding `sema_enabled` notification.
To fix this, just properly die on `SIGTERM` by calling `abort`.
Add cross-compilation flags for the newly added Swift source in `lib/ASTGen/`,
similar to how `SwiftCompilerSources/` is already cross-compiled for other
platforms. Make sure the Swift source in the compiler builds and links against
`SWIFTLIB_DIR` in this cross-compilation build directory, not the one that comes
with the native host compiler.
This requires changing the dependency chain in `CROSSCOMPILE` mode, as normally
the Swift compiler is built first when building natively for the host, then it's
used to build the stdlib. However, when cross-compiling the toolchain, the stdlib
must be cross-compiled first by the host compiler, then the portions of the
Swift compiler written in Swift must be cross-compiled with that new stdlib. All
these dependency changes simply change that compilation order when cross-compiling,
including removing the dependency that the Swift compiler is built before the
stdlib when cross-compiling the Swift compiler.
All changes in this pull are gated on the `CROSSCOMPILE` mode, so they will
not affect any of the existing CI or build presets.
Remove this bit from function decls and closures.
Instead, for closures, infer it from the presence
of a single return or single expression AST node
in the body, which ought to be equivalent, and
automatically takes result builders into
consideration. We can also completely drop this
query from AbstractFunctionDecl, replacing it
instead with a bit on ReturnStmt.
Rather than doing the transform in the parser, and
then potentially undoing it in Sema, move the
entire transform into Sema. This also lets us
unify the logic between function decls and
closures, and allows ASTGen to benefit from it.
Performing a related identifiers request on `self` returns an empty result because `self` is not an identifier. We thus can’t retrieve the first location to compute the old name.
rdar://121668042
If the file didn’t exist on disk, `fileSystem->getRealPath` returns an empty string, which means we can’t find the `InputBuffer` and thsu won’t run solver-based cursor info. There’s no reason to realpath `PrimaryInputPath`, `getMemoryBuffer` already does that.
rdar://120737244
It's not clear that its worth keeping this as a
base class for SerializedAbstractClosure and
SerializedTopLevelCodeDecl, most clients are
interested in the concrete kinds, not only whether
the context is serialized.
ASL is deprecated in macOS 10.12. It may be time to transition to os_log now
that deployment targets have been raised to 10.12, but until that project
starts these warnings are just pollution.
Filed rdar://121076739 to track adoption of `os_log()` if appropriate.
While we don't want to return non-editable base names for Edit-All-In-Scope, we do want to return them if the related identifiers response is used as the input for find-syntactic-rename-ranges.
Add the swiftmodule paths for ASTGen via
`-add_ast_path` to the public linker flags such
that downstream linking picks them up, allowing
LLDB to load them when debugging. Also switch
SwiftCompilerModules to using public linker
flags instead of adding the linker flags in
`_add_swift_runtime_link_flags`.
This allows building sourcekitd and swift-refactor with `SWIFT_BUILD_SWIFT_SYNTAX=NO`. In these builds, the `relatedidents` and `find-syntactic-rename-ranges` requests will always return an error.
The implementation is not 100% perfect but I don’t think it’s worth putting too much effort into it passing more information down in the parser if 'repeat' and 'each' are valid if we are going to remove the current parser anyway.
rdar://95725895
We should (and do) have one new name for the entire rename operation, not a separate new name for different positions at which the renamed symbol occurs.
