The diagnostic group documentation now point to the swift.org URL rather
than the toolchain path, so it no longer needs to be passed all the way
through sourcekitd.
Resolves rdar://151500502.
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
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.
These libraries formed a strongly connected component in the CMake build graph. The weakest link I could find was from IDE to FrontendTool and Frontend, which was necessitated by the `CompileInstance` class (https://github.com/apple/swift/pull/40645). I moved a few files out of IDE into a new IDETools library to break the cycle.
