Resolving cursor info is async and can occur after the request has been
deleted, make sure to take a copy of the `USR` (which is part of that
request).
Resolves rdar://137320169.
Providing these is a bit of a layering violation,
the parser shouldn't care about these options (there
does seem to be one current use of `TypeCheckerOpts`
in the parser for designated operator types, but
that's a legacy feature that was never officially
supported).
The "buffer ID" in a SourceFile, which is used to find the source file's
contents in the SourceManager, has always been optional. However, the
effectively every SourceFile actually does have a buffer ID, and the
vast majority of accesses to this information dereference the optional
without checking.
Update the handful of call sites that provided `nullopt` as the buffer
ID to provide a proper buffer instead. These were mostly unit tests
and testing programs, with a few places that passed a never-empty
optional through to the SourceFile constructor.
Then, remove optionality from the representation and accessors. It is
now the case that every SourceFile has a buffer ID, simplying a bunch
of code.
Introduces the new DeclarationsArrayBuilder and adds it to the
EditorConsumer. Declaration info always includes a kind, offset, and
length, and includes a USR where applicable.
As the USR is already available for editor.open.interface type requests,
this doesn't compute any new information, it just exposes more of what's
there already.
Building the generated interface for WinSDK can overflow the stack.
Treat it as a semantic request to run it on a large stack.
Fixesswiftlang/sourcekit-lsp#1115
rdar://123944504
We ran SwiftParser in `handlePrimaryAST` for related identifiers. That function is called on a dispatch queue with reduced stack size and could cause the parser to stack overflow if the program is very nested.
Run `handlePrimaryAST` on a deep stack for this request to fix the issue.
rdar://129960285
Remove `deque` from files it isn't actually used in. Add it and `stack`
to files that it is - presumably they were previously transitively found
through other includes.
Separate swift-syntax libs for the compiler and for the library plugins.
Compiler communicates with library plugins using serialized messages
just like executable plugins.
* `lib/swift/host/compiler/lib_Compiler*.dylib`(`lib/CompilerSwiftSyntax`):
swift-syntax libraries for compiler. Library evolution is disabled.
* Compiler (`ASTGen` and `swiftIDEUtilsBridging`) only depends on
`lib/swift/host/compiler` libraries.
* `SwiftInProcPluginServer`: In-process plugin server shared library.
This has one `swift_inproc_plugins_handle_message` entry point that
receives a message and return the response.
* In the compiler
* Add `-in-process-plugin-server-path` front-end option, which specifies
the `SwiftInProcPluginServer` shared library path.
* Remove `LoadedLibraryPlugin`, because all library plugins are managed
by `SwiftInProcPluginServer`
* Introduce abstract `CompilerPlugin` class that has 2 subclasses:
* `LoadedExecutablePlugin` existing class that represents an
executable plugin
* `InProcessPlugins` wraps `dlopen`ed `SwiftInProcPluginServer`
* Unified the code path in `TypeCheckMacros.cpp` and `ASTGen`, the
difference between executable plugins and library plugins are now
abstracted by `CompilerPlugin`
Complete ownership specifiers such as `consuming`,
`borrowing`, and `inout` in parameter type
position. While here, also complete `isolated`.
rdar://127261573
