Support null and negative integer request IDs #285
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ebkalderon
force-pushed
the
support-null-negative-request-ids
branch
10 times, most recently
from
a24ab95
to
ed71395
Compare
Despite the Language Server Protocol specification claiming otherwise [here], the `id` field of a request object _can_ be `null` according to the JSON-RPC 2.0 specification: [here]: https://microsoft.github.io/language-server-protocol/specification#requestMessage Although the use of `null` as a request ID value is rare in practice and explicitly discouraged by the JSON-RPC 2.0 specification, we must be compatible with as many JSON-RPC client implementations as possible. Therefore, we must support parsing `null` request IDs in incoming messages, even if we never emit them ourselves.
Although a rare occurrence, the use of negative integer values as request IDs is nonetheless permitted by the JSON-RPC 2.0 specification. To ensure compatibility with as many JSON-RPC client implementations as possible, we must support parsing negative IDs, even though we never emit them ourselves.
ebkalderon
force-pushed
the
support-null-negative-request-ids
branch
from
ed71395
to
77a871e
Compare
ebkalderon
added a commit
that referenced
this pull request
Feb 14, 2022
The `tower-lsp-macros` crate should have been released with a minor version bump, not a patch version bump. This commit updates the versions appropriately in the `Cargo.toml` manifests in preparation for yanking and re-releasing the same code under the new designations `tower-lsp` 0.15.1 and `tower-lsp-macros` 0.5.0. This is to address a semver incompatibility introduced in PR #285.
ebkalderon
added a commit
that referenced
this pull request
Feb 14, 2022
The `tower-lsp-macros` crate should have been released with a minor version bump, not a patch version bump. This commit updates the versions appropriately in the `Cargo.toml` manifests in preparation for yanking and re-releasing the same code under the new designations `tower-lsp` 0.15.1 and `tower-lsp-macros` 0.5.0. This is to address a semver incompatibility introduced in PR #285.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Added
Id::Nullenum variant.DefaultforId.nulland negative integer request IDs parse successfully.Changed
Id::Number(u64)toId::Number(i64).Response::error()constructor to acceptIdinstead ofOption<Id>.Response::id()method to return&Idinstead ofOption<&Id>.Response::into_parts()method to return(Id, _)instead of(Option<Id>, _)std::sync::atomic::AtomicU32to track client request IDs instead ofAtomicU64. This ensures the incrementing IDs will always cast losslessly into ani64primitive data type.Both of these request ID types are rare and bizarre and their use is generally discouraged by the JSON-RPC 2.0 spec, but are nonetheless permitted by the standard. Since we wish
tower-lspto be compatible with as many JSON-RPC client libraries as possible, we must support parsingnulland negative integer request IDs, even if we never emit them ourselves.