The `lsp-server` crate is currently published without license files, which is
needed when packaging in Linux distributions.
Symlink the files from the repository root so they are kept in sync.
Test showing the files get picked up by `cargo package`:
```
michel in rust-analyzer/lib/lsp-server on add-lsp-server-license [+] is 📦 v0.7.6 via 🐍 v3.12.1 (.venv311) via 🦀 v1.76.0
⬢ [fedora:39] ❯ cargo package --allow-dirty --no-verify
Updating crates.io index
Packaging lsp-server v0.7.6 (/home/michel/src/github/rust-lang/rust-analyzer/lib/lsp-server)
Updating crates.io index
Packaged 12 files, 59.6KiB (16.3KiB compressed)
michel in rust-analyzer/lib/lsp-server on add-lsp-server-license [+] is 📦 v0.7.6 via 🐍 v3.12.1 (.venv311) via 🦀 v1.76.0
⬢ [fedora:39] ❯ tar tf ../../target/package/lsp-server-0.7.6.crate | grep LICENSE
lsp-server-0.7.6/LICENSE-APACHE
lsp-server-0.7.6/LICENSE-MIT
```
Signed-off-by: Michel Lind <salimma@fedoraproject.org>
Sered no longer uses blobs as of
https://github.com/serde-rs/serde/pull/2590
As such, there's no longer need for us to pin it.
Note that this doesn't upgrade serde version we use: I am fairly
confident that the blobs are already there are fine, and now I am fairly
confident that all future versions of serde will be fine as well.
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.
Fix: a TODO and some clippy fixes
- fix(todo): implement IntoIterator for ArenaMap<IDX, V>
- chore: remove unused method
- fix: remove useless `return`s
- fix: various clippy lints
- fix: simplify boolean test to a single negation
More APIs for `la_arena::IdxRange`
```rust
impl<T> ExactSizeIterator for IdxRange<T>;
impl<T> Arena<T> {
pub fn alloc_many<II: IntoIterator<Item = T>>(&mut self, iter: II) -> IdxRange<T>;
}
```
1. There are no currently ways to get `IdxRange` without manually offseting `Idx`. Providing a method for multiple-allocation simplifies this process and makes it less error-prone.
2. `IdxRange: ExactSizeIterator` makes `iter.zip(range).rev()` possible. Since `Zip: DoubleEndedIterator` requires all its arguments to be `ExactSizeIterator`. It also ease the usage for, eg. `len()`.
3. Fixed a typo.
I noticed that `IdxRange::end` may be invalid. Is it good to return `Idx` instead of `RawIdx`?
