This brings up the ability to compute cursor info results using the completion-like type checking paradigm, which an reuse ASTContexts and doesn’t need to type check the entire file.
For now, the new implementation only supports cursor info on `ValueDecl`s (not on references) because they were easiest to implement. More cursor info kinds are coming soon.
At the moment, we only run the new implementation in a verification mode: It is only invoked in assert toolchains and when run, we check that the results are equivalent to the old implementation. Once more cursor info kinds are implemented and if the SourceKit stress tester doesn’t find any verification issues, we can enable the new implementation, falling back to the old implementation if the new one didn’t produce any results.
We will be using the string serialized results to verify that solver-based cursor info results match the old implementation. This is necessary because cursor info results on their own contain stack references that cannot be stored.
This way, each kind of `ResolvedCursorInfo` can define its own set of properties and it’s obvious which properties are used for which kind. Also switch to getters and setters because that makes it easier to search for usages of properties by looking at the call hierarchy of the getter / setter.
Separate 'sourcekitd/lib/API/Requests.cpp' to a library
'sourcekitdService' so the XPC client libary (i.e.
sourcektid.framework/sourcekid) doesn't include unnecessary code.
rdar://102765542
`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
Ensure that we link `swift_CompilerPluginSupport` into the compiler and
SourceKit, and set the rpath appropriately to find the library in its
installed location.
A number of driver tests copy the driver executable into a temporary
directory to isolate it from the build tree. Also copy the plugin
support library into its appropriate place near the driver executable
to ensure these tests keep working. To help with this, add a
`swift_swift_parser` lit feature, which we can use in tests that
involve the new parser's capabilities.
`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
This change does not cover all uses of the old API. Other warnings are worked around in llvm by https://github.com/apple/llvm-project/pull/5618
rdar://102362022
IDE/Refactoring had dependencies to libswiftIndex, but libswiftIndex
also depends on libswiftIDE (SourceEntityWalker, etc.)
To break libswiftIndex <-> libswiftIDE dependency cycle, move
"refactoring" related files to a new library 'libswiftRefactoring'
rdar://101692282
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.
