Stream: t-compiler/rust-analyzer

Topic: VS Code requirement is too high


Jonas Schievink [he/him] (Dec 21 2020 at 10:31, on Zulip):

Unable to install extension 'matklad.rust-analyzer' as it is not compatible with VS Code '1.51.1'.

Why are we bumping the VS Code requirement so aggressively? NixOS is still on 1.51.1, so using rust-analyzer master is impossible there.

Laurențiu (Dec 21 2020 at 10:39, on Zulip):

CC https://github.com/rust-analyzer/rust-analyzer/pull/6779

Laurențiu (Dec 21 2020 at 10:44, on Zulip):

We used to support only the latest version, but now that's supposed to be the latest two versions

matklad (Dec 21 2020 at 10:45, on Zulip):

Hm, good call on the latest two versions

matklad (Dec 21 2020 at 10:46, on Zulip):

guess it makes sense to revert that on the reelase branch...

matklad (Dec 21 2020 at 11:13, on Zulip):

Hm, thinking just a bit more about it, seems like "two releases" strategy is not tenable... cc @Jeremy Kolb .

The problem is that the underlying LSP library we use uses "latest stable" policy. This is understandable -- they need to bind to the latest VS Code APIs to use new features. And we need to use the latest library to have access to latest features as well. Sticking to an older release is not an option imo: supporting older vscodes is good, but enforcing older vscodes on everyone is not.

matklad (Dec 21 2020 at 11:14, on Zulip):

I think the simplest thing we can do is reverting to the "latest stable" policy, + a provision that old extensions work with new server binary

matklad (Dec 21 2020 at 11:14, on Zulip):

(which, sadly, isn't the case in today's release)

matklad (Dec 21 2020 at 11:16, on Zulip):

Some alternatives are:

Jeremy Kolb (Dec 21 2020 at 15:00, on Zulip):

I'm not sure how to solve the vscode-languageclient versioning. We could stick with the latest stable package but then we'd be missing out on things like semantic highlighting for 9 months so I'm not a big fan of that option.

Jeremy Kolb (Dec 21 2020 at 15:02, on Zulip):

I think it may make sense to have some sort of extension/server compatibility matrix

matklad (Dec 21 2020 at 15:03, on Zulip):

I think the "doesn't die on startup" would be good enough level of compat

matklad (Dec 21 2020 at 15:03, on Zulip):

see https://github.com/gluon-lang/lsp-types/pull/193

matklad (Dec 21 2020 at 15:04, on Zulip):

(and https://github.com/serde-rs/serde/issues/1908)

Florian Diebold (Dec 21 2020 at 15:05, on Zulip):

ah, that's probably rust-analyzer#6979 then as well...

Florian Diebold (Dec 21 2020 at 15:05, on Zulip):

... or at least related to that?

matklad (Dec 21 2020 at 15:09, on Zulip):

:(

matklad (Dec 21 2020 at 15:09, on Zulip):

:( :( :(

matklad (Dec 21 2020 at 15:10, on Zulip):

that's me messing-up release

matklad (Dec 21 2020 at 15:10, on Zulip):

I think...

matklad (Dec 21 2020 at 15:12, on Zulip):

Hm, can anyone spot the bug in https://github.com/gluon-lang/lsp-types/pull/193/files ?

Jeremy Kolb (Dec 21 2020 at 15:18, on Zulip):

It looks right...

Jeremy Kolb (Dec 21 2020 at 15:19, on Zulip):

OH

Jeremy Kolb (Dec 21 2020 at 15:21, on Zulip):

The existing code is wrong. According to the spec it needs to be groups_on_label.

Jeremy Kolb (Dec 21 2020 at 15:23, on Zulip):

That might be causing deserialize to fail

Laurențiu (Dec 21 2020 at 16:40, on Zulip):

Is https://github.com/rust-analyzer/rust-analyzer/issues/6414#issuecomment-749063940 the same problem?

Last update: Jul 26 2021 at 13:15UTC