'sourcekitd' itself should not call 'swift::' functions. It should just
deserialize the request, execute the logic in LangSupport, then serialize
the result.
Previously, SourceKit requests are handled in a single
'handleRequestImpl'/'handleSemanticRequest' with basically a giant
'if (ReqUID == RequstXXX)' branches. Some request parameters are
extracted at the top of the function, but not all request kind used all
of them.
Factor out each handling logic to its own function, and check/extract
request parameters in it. This makes it clear that which request uses
what parameters, and how they are handled.
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
