switch out lsp-types for gen-lsp-types

[BenjaminBrienen]

Blocked on:

• implement From<&str> for string enums with custom values ribru17/gen-lsp-types#8
• LspRequestMethods::Custom should take a &'static str ribru17/gen-lsp-types#9
• Collision between crate::Id and crate::generated::Id ribru17/gen-lsp-types#10
• Move items in root module to mod json_rpc to avoid name collisions ribru17/gen-lsp-types#11
• Support constructing string enums which support custom values in const contexts ribru17/gen-lsp-types#14

Alternative to: #22108

[ribru17]

Heads up @BenjaminBrienen I just pushed v0.4.0, will probably affect this PR

[BenjaminBrienen]

I already updated to it :)

[BenjaminBrienen]

I'm assuming you would like a side of squash with this meal

[ribru17]

Fyi, the lsp-types issues fixed in gen-lsp-types are:

• Add LSP 3.18 SnippetTextEdit support (proposed) gluon-lang/lsp-types#310
• Eq and Hash for all Param/Result types? gluon-lang/lsp-types#308
• The new Uri type in 0.96.0 is hard to use and have almost no interoperability gluon-lang/lsp-types#284
• Why type names of this crate don't follow the spec ? gluon-lang/lsp-types#278
• Auto-generate Protocol Bindings gluon-lang/lsp-types#277
• Derive Default for CodeActionOptions gluon-lang/lsp-types#260
• many types don't derive Hash even though they can gluon-lang/lsp-types#245
• FoldingRange.kind is limited gluon-lang/lsp-types#93

Along with:

rust-analyzer/crates/rust-analyzer/src/bin/main.rs

Line 218 in 4c57da3

// lsp-types has a typo in the `/capabilities/workspace/diagnostics` field, its typoed as `diagnostic`

[BenjaminBrienen]

I already have a draft PR based on top of this one that implements the split and uses the capability properly, so I just removed the comment for now. Is that fine?

[DropDemBits]

Going through all of the it.method == R::METHOD changes made me realize that there's no request-equivalent helper function of notification_is 😅

My main concern though is if the file:// scheme is still required though, as I think the tests ensure that we're emitting self-consistent values rather than if those values actually make sense for the LS client.

View changes since this review

[DropDemBits]

I hadn't known about the draft PR, sorry!

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[BenjaminBrienen]

It is failing because of something to do with the difference between resource operation and document change, I think. It is just one slow test. I couldn't figure out the reason.

[rustbot]

☔ The latest upstream changes (possibly #22284) made this pull request unmergeable. Please resolve the merge conflicts.

[Veykril]

If you could rebase once more, will get this merged then 🙏
Thanks!

[stothej]

@Veykril If I can ask a question from the peanut gallery... Isn't there some inherent risk with swapping to a library that's less than 2 months old, from an (admittedly unmaintained) stable one? It's also not a drop-in replacement, unfortunately (hence the 2k line diff). As an example, the version in Cargo.toml is already 2 versions out of date (0.4.0 instead of 0.6.0).

I've seen @ribru17 send PRs of this library to a lot of other projects who are depending on gluon's lsp_types - and then referencing this PR as social proof for it going in. That feels gross to me - but OSS libs are a chicken/egg problem, so there's that.

Anyways, just raising a flag as someone who maintains a bunch of OSS projects and LSP servers (using lsp_server) - take this comment with whatever grains of salt are required.

Personally I was hoping that Microsoft's lsprotocol would have gone somewhere, and solved this problem. I've vendored Helix's lsp-types in my projects for now.

Edit: Changed spam to send - as the former sounded too much like a personal attack, while this is a comment about technical stability and long-term viability.

[lnicola]

@stothej we're switching from a hand-written crate to an automatically generated one, which is somewhat we've wanted anyway. Even if the author goes away, we can take over or fork it, and it's going to be easier. Most of the 2000-line diff is to test outputs (because fields were missing in the old crate) and different module and struct names.

and then referencing this PR as social proof for it going in

Which seems totally fair, given that ribru17 listened to our feedback incorporated the changes we've requested.