fix: avoid problematic serde release

serde 1.0.172 and up rely on opaque non-reproducible binary blobs to
function, explicitly not providing a library-level opt-out.

This is problematic for two reasons:

- directly, unauditable binary blobs are a security issue.
- indirectly, it becomes much harder to predict future behaviors of the
  crate.

As such, I am willing to go on a limb here and forbid building
rust-analyzer with those versions of serde. Normally, my philosophy is
to defer the choice to the end user, but it's also a design constraint
of rust-analyzer that we don't run random binaries downloaded from the
internet without explicit user's concent.

Concretely, this upper-bounds serde for both rust-analyzer workspace, as
well as the lsp-server lib.

See serde-rs/serde#2538 for wider context.

Author: matklad

Cargo.lock

@@ -97,7 +97,8 @@ smallvec = { version = "1.10.0", features = [
 smol_str = "0.2.0"
 nohash-hasher = "0.2.0"
 text-size = "1.1.0"
-serde = { version = "1.0.156", features = ["derive"] }
+# See https://github.com/serde-rs/serde/issues/2538#issuecomment-1684517372 for why we pin serde
+serde = { version = "1.0.156, < 1.0.172", features = ["derive"] }
 serde_json = "1.0.96"
 triomphe = { version = "0.1.8", default-features = false, features = ["std"] }
 # can't upgrade due to dashmap depending on 0.12.3 currently

Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "lsp-server"
-version = "0.7.2"
+version = "0.7.3"
 description = "Generic LSP server scaffold."
 license = "MIT OR Apache-2.0"
 repository = "https://github.com/rust-lang/rust-analyzer/tree/master/lib/lsp-server"
@@ -9,7 +9,8 @@ edition = "2021"
 [dependencies]
 log = "0.4.17"
 serde_json = "1.0.96"
-serde = { version = "1.0.156", features = ["derive"] }
+# See https://github.com/serde-rs/serde/issues/2538#issuecomment-1684517372 for why we pin serde
+serde = { version = "1.0.156, < 1.0.172", features = ["derive"] }
 crossbeam-channel = "0.5.6"
 
 [dev-dependencies]