- Ensure that no callbacks are called when either of these mutexes are held:
- `SwiftASTConsumer::CancellationRequestCallbackAndIsCancelledMtx`
- `ASTBuildOperation::DependencyStampsMtx`
- Exception: We allow calls to `getBuferStamp` because that doesn’t claim any locks)
- No change was necessary here
- `ASTBuildOperation::ConsumersAndResultMtx`
- `ASTBuildOperation::CacheMtx`
- No change was necessary here
- `ASTBuildOperation::ScheduledConsumersMtx`
- Make sure we always inform the consumers asynchronously, even if the operation was already cancelled when the consumer got enqueued by introducing `ConsumerNotificationQueue`
- Ensure that all callbacks to `SwiftASTConsumer` (i.e. `requestCancellation` and `handlePrimaryAST`, `failed`, `cancelled`) are performed asyncronously from a queue to avoid deadlocks
rdar://110357502
This fixes a deadlock that could occur when a cursor info request is cancelled while another one is inside the cancellation callback. The schematic deadlock backtrace is
```
sourcekitd::cancelRequest
SourceKit::RequestTracker::cancel -> holds RequestTracker.RequestsMtx
anonymous func in SourceKit::SwiftASTManager::processASTAsync
SourceKit::SwiftASTConsumer::requestCancellation
anonymous func in ASTBuildOperation::addConsumer -> tries to get ASTBuildOperation.ConsumersAndResultMtx
resolveCursor
SourceKit::SwiftASTManager::processASTAsync
SourceKit::SwiftASTConsumer::requestCancellation
anonymous func in ASTBuildOperation::addConsumer
[probably inlined] ASTBuildOperation::requestConsumerCancellation -> holds ASTBuildOperation.ConsumersAndResultMtx
resolveCursor::CursorInfoConsumer::cancelled
anonymous func in SourceKit::SwiftLangSupport::getCursorInfo
anonymous func in handleRequestCursorInfo
reportCursorInfo
anonymous func in sourcekitd::handleRequest -> tries to get RequestTracker.RequestsMtx
```
rdar://110357502
Record up to two errors emitted when we fail to
load a module for interface generation, and include
these errors in the message we pass back to the
editor. This should help us better pin down the
reason why interface generation failed.
rdar://109511099
This source location will be used to determine whether to add a name lookup
option to exclude macro expansions when the name lookup request is constructed.
Currently, the source location argument is unused.
Expand macros in the specified source file syntactically (without any
module imports, nor typechecking).
Request would look like:
```
{
key.compilerargs: [...]
key.sourcefile: <file name>
key.sourcetext: <source text> (optional)
key.expansions: [<expansion specifier>...]
}
```
`key.compilerargs` are used for getting plugins search paths. If
`key.sourcetext` is not specified, it's loaded from the file system.
Each `<expansion sepecifier>` is
```
{
key.offset: <offset>
key.modulename: <plugin module name>
key.typename: <macro typename>
key.macro_roles: [<macro role UID>...]
}
```
Clients have to provide the module and type names because that's
semantic.
Response is a `CategorizedEdits` just like (semantic) "ExpandMacro"
refactoring. But without `key.buffer_name`. Nested expnasions are not
supported at this point.
Solver based results are fast within a function, where the `ASTContext`
can be re-used. But it is significantly slower than the AST based
results when outside of a function. Instead of using solver based as the
primary results, only use them as a fallback for when AST based fails.
Resolves rdar://108930110.
Introduce a new key `generated_buffers`, which
stores an array of generated buffers. These
include the buffer text, as well as its original
location and any parent buffers.
While here, also fix rdar://107281079 such that
only apply the filename fallback logic to the
pretty-printed Decl case. We ought to remove this
fallback once the editor can handle it though.
rdar://107281079
rdar://107952288
* Factor out ASTContext plugin loading to newly introduced 'PluginLoader'
* Insert 'DependencyTracker' to 'PluginLoader'
* Add dependencies right before loading the plugins
rdar://104938481
Driver uses its path to derive the plugin paths (i.e.
'lib/swift/host/plugins' et al.) Previously it was a constant string
'swiftc' that caused SourceKit failed to find dylib plugins in the
toolchain. Since 'SwiftLangSupport' knows the swift-frontend path,
use it, but replacing the filename with 'swiftc', to derive the plugin
paths.
rdar://107849796
Only return macros that are valid in their current position, ie. an
attached macro is not valid on a nominal.
Also return freestanding expression macros in code block item position
and handle the new freestanding code item macros.
Resolves rdar://105563583.
This ensures that interface gen reports an error when importing a framework Swift module
that also imports the underlying C++ module into Swift, when interop is disabled, so that
we can retry the interface gen with interop enabled.
Pass back the original location (ie. where the macro was expanded, not
the location that the generated code would be inserted) for cursor info
and indexing. Also mark any declarations/references within generated
source as implicit.
Resolves rdar://107209132.
Update to have a single refactoring collection method for cursor
refactorings and another for ranges. The various functions were only
needed because of the extra availability information on renames, so just
give that to all refactorings.
Make a single 'PluginRegistry' and share it between SwiftASTManager,
IDEInspectionInstance, and CompileInstance. And inject the plugin
registry to ASTContext right after 'CompilerInstance.setup()'
That way, all sema-capable ASTContext in SourceKit share a single
PluginRegistry.
Update requests to handle being passed a separate `key.primary_file`
which specifies the file to use for building the AST. `key.sourcefile`
is then the file to find in `SourceManager`, which could be a generated
buffer.
Resolves rdar://106863186.
This hooks up the cursor info infrastructure to be able to pass through multiple, ambiguous results. There are still minor issues that cause solver-based cursor info to not actually report the ambiguous results but those will be fixed in a follow-up PR.
Rather than using `ModuleDecl::isSystemModule()` to determine whether a
module is not a user module, instead check whether the module was
defined adjacent to the compiler or if it's part of the SDK.
If no SDK path was given, then `isSystemModule` is still used as a
fallback.
Resolves rdar://89253201.
Retrieving local rename ranges and the local rename refactoring both had
almost identical methods, except for the addition of retrieving the
outermost shadowed decl that was added a couple months back. Merge them.
Resolves rdar://106529370.
This adds a new `primary_file` key, which defaults to `sourcefile`. For
nested expansions, `primary_file` should be set to the containing file
and `sourcefile` to the name of the macro expansion buffer.
