`requestIsEnableBarriers` and `requestIsBarrier` call `SKDUIDFromUIdent`. What I didn’t know, was that `SKDUIDFromUIdent` can send XPC requests to the client to translate UIDs via `sourcekitd_set_uid_handlers`.
Since we were calling `requestIsEnableBarriers` directly from the XPC server’s main queue, and the UID handler sends an XPC request synchronously, we could get into a deadlock situation.
Immediately jump onto a serial background queue (`msgHandlingQueue`) in `sourcekitdServer_peer_event_handler` so that the main queue is free to execute the UID handler. This more closely matches the behavior before I introduced barriers as well, where we were always immediately jumping onto a concurrrent `msgHandlingQueue`.
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.
Instead of being a part of 'directDependencies' on a module dependency info, make them a separate array of dependency IDs for Swift Source and Textual modules.
This will allow clients to still distinguish direct module dependencies imported from a given module, versus dependencies added because direct/transitive Clang module dependencies have Swift overlays.
This change does *not* remove overlay dependencies from 'directDependencies' yet, just adds them as a separate field on the module details info. A followup change will remove overlay and bridging header dependencies from 'directDependencies' once the clients have had a chance to adopt to this change.
On macOS it is possible for one application to contain Swift modules compiled
for different triples that are incompatible as far as the Swift compiler is
concerned. Examples include an iOS simulator application hunning on a macOS
host, or a macCatalyst application running on macOS. A debugger might see
.swift_ast sections for all triples at the same time. This patch adds an
interface to let the client provide a triple to filter Swift modules in an
ASTSection.
rdar://107869141
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
When getTopLevelDeclsForDisplay is called on an imported module, it may
lists non-public decls. If we they try to inject the conformance on
Sendable on internal types, the compiler may crash on failing to
deserialize internal details. As a fix, let's only inject the
conformance on public or package types.
rdar://95430471
C stdlib headers are part of "Darwin"/"Glibc" clang module.
If a Swift file imports a bridging headers and that has '#include'
C stdlib headers, Swift compiler implicitly imports "Darwin"/"Glibc"
overlay modules. That violates dependency layering. I.e. Compiler
depends on Darwin overlay, Darwin overlay is created by the compiler.
rdar://107957117
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
