The URI standard RFC 3986 is ambiguous about whether percent encoding and their represented characters are considered equivalent. VS Code considers them equivalent and treats them the same:
```js
vscode.Uri.parse("x://a?b=xxxx%3Dyyyy").toString() -> 'x://a?b%3Dxxxx%3Dyyyy'
vscode.Uri.parse("x://a?b=xxxx%3Dyyyy").toString(/*skipEncoding=*/true) -> 'x://a?b=xxxx=yyyy'
```
This causes issues because SourceKit-LSP's macro expansion URLs encoded by URLComponents use `=` do denote the separation of a key and a value in the outer query. The value of the `parent` key may itself contain query items, which use the escaped form '%3D'. Simplified, such a URL may look like `scheme://host?parent=scheme://host?line%3D2`.
But after running this through VS Code's URI type `=` and `%3D` get canonicalized and are indistinguishable.
To avoid this ambiguity, always percent escape the characters we use to distinguish URL query parameters, producing the following URL: `scheme://host?parent%3Dscheme://host%3Fline%253D2`.
Now that all the types that model test projects are suffixed `Project` instead of `Workspace`, the `ws` abbreviation doesn‘t make sense. It also never really fit with the new style of avoiding abbreviations. Rename all occurrences to `project`.
rdar://124727401
Basically everything will be decoded as ClangWorkspaceSettings, even if it has nothing to
do wit hit, yielding for example:
```
clangd(LanguageServerProtocol.ClangWorkspaceSettings(compilationDatabasePath: nil, compilationDatabaseChanges: nil))
```
This breaks at least my case of using WorkspaceSettingsChange. This patch adds a - maybe bandaid - fix for that.
Furthermore I removed one Test, as it - AFAIU - broke the invariant that none of the attributes
of ClangWorkspaceSettings may be nil.
Add `.swift-format` to the repo and format the repo with `swift-format`.
This commit does not add any automation to enforce formatting of sourcekit-lsp in CI. The goal of this commit is to get the majority of source changes out of the way so that the diff of actually enforcing formatting will have fewer changes or conflicts.
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.
