This appears to have been accidentally removed in
17f656865d, the `children` field is
optional in the LSP spec.
Change-Id: I1055658c8f09873279d676fee0daff02fa59e3f8
* Add LSP types and server stubs for call hierarchy support
* Update CMakeLists.txt for new LSP types
* Call hierarchy misc fixes
* Minor PositionRangeArray fixes to simplify codable conformance
* Add CodingTests for PositionRangeArray and CallHierarchy encoding
The LSP spec requires us to omit keys for nil values rather than using
the JSON `null` constant in most places. This change to CustomCodable
allows us to do it automatically using CustomCodable, removing one of
the limitations of the property wrapper.
The idea for the adding overloads of `encode` and `decode` came from
https://forums.swift.org/t/pre-pitch-codable-customization-using-propertywrappers/30244/
URL can in fact store URIs, it just doesn't have a very nice API to
interact with them. As long as we only operate on absoluteString, we
should be fine though. So instead of implementing the logic for
detecting file URLs ourselves, we can just use a URL as storage for
DocumentURI.
According to the LSP specification, arbitrary URIs can be used as
document identifiers. Instead of internally assuming that all URIs are
URLs, use a DocumentURI enum to represent URIs. These can either be file
URLs or other URIs whose value as treated as an opaque string.
We will be able to split the LSP modules off later. These LSP modules
will provide the ability to write custom LSP servers and clients in
Swift. The sourcekit-lsp repository will build on top of this new
package to provide an LSP implementation that creates a language server
for Swift and C-based-languages.
This lets us use the `Range<Position>` without manually converting back
and forth in the majority of cases. See the note on HoverResponse for
the behaviour with Optional that makes us have to provide a custom
Codable implementation in two places that used to be synthesized.
We are tied to using a SwiftPM that matches the toolchain, so upgrade
from 0.3.0 to .branch("master") and add a pins file to manage updating
that dependency.
This was driven by changes that broke loading packages being developed
with newer version of SwiftPM when using the 0.3.0 tag of libSwiftPM.
However, the changes seem to work when going in the other direction, so
using the newer libSwiftPM hasn't caused any known regressions for using
older toolchain versions (not guarantteed and not tested extensively
though).
This fixes using the latest (November 13) toolchain snapshot on macOS.
On Linux there are other issues not specific to LSP.
