6c46b98a95
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 https://github.com/serde-rs/serde/issues/2538 for wider context. |
||
|---|---|---|
| .. | ||
| la-arena | ||
| line-index | ||
| lsp-server | ||
| README.md | ||
lib
Crates in this directory are published to crates.io and obey semver.
They could live in a separate repo, but we want to experiment with a monorepo setup.
We use these crates from crates.io, not the local copies because we want to ensure that rust-analyzer works with the versions that are published. This means if you add a new API to these crates, you need to release a new version to crates.io before you can use that API in rust-analyzer.
To release new versions of these packages, change their version in Cargo.toml. Once your PR is merged into master a workflow will automatically publish the new version to crates.io.
While prototyping, the local versions can be used by uncommenting the relevant lines in the
[patch.'crates-io'] section in Cargo.toml