4972: Gzip artifacts r=Veetaha a=Veetaha
[Here is the test release](https://github.com/Veetaha/rust-analyzer/releases/tag/2020-06-21)
Change in size: `~ 25 MB -> ~ 8 MB (gzipped)`
The time to gzip during the dist build takes a somewhat considerable amount of time tho.
Having already compiled artifacts this takes in debug mode:
```
~/dev/rust-analyzer (feat/gzip-binaries) $ time cargo xtask dist
Finished dev [unoptimized] target(s) in 0.06s
Running `target/debug/xtask dist`
> cargo build --manifest-path ./crates/rust-analyzer/Cargo.toml --bin rust-analyzer --release
Finished release [optimized] target(s) in 0.05s
> strip ./target/release/rust-analyzer
real 0m34.331s
user 0m34.245s
sys 0m0.078s
```
In release mode this is much faster:
```
~/dev/rust-analyzer (feat/gzip-binaries) $ time cargo run -p xtask --release -- dist
Finished release [optimized] target(s) in 0.04s
Running `target/release/xtask dist`
> cargo build --manifest-path ./crates/rust-analyzer/Cargo.toml --bin rust-analyzer --release
Finished release [optimized] target(s) in 0.06s
> strip ./target/release/rust-analyzer
real 0m2.401s
```
**[UPD]** adding a profile override for `miniz_oxide` does the thing to ensure good performrance
We might need to notify all other ra plugins' maintainers about the change in our GH releases if we merge this PR, or we could leave uncompressed files along with gzipped for a while until everyone migrates.
Co-authored-by: Veetaha <veetaha2@gmail.com>
Co-authored-by: bjorn3 <bjorn3@users.noreply.github.com>
Override miniz_oxide to build it with optimizations
Building this crate with optimizations decreases the gzipping
part of `cargo xtask dist` from `30-40s` down to `3s`,
the overhead for `rustc` to apply optimizations is miserable on this background
5252: Fix symbol search in salsa r=matklad a=matklad
Previous solution for binning paths into disjoint directories was
simple and fast -- just a single binary search.
Unfortunatelly, it wasn't coorrect: if the ditr are
/d
/d/a
/d/c
then partitioning the file /d/b/lib.rs won't pick /d as a correct
directory.
The correct solution here is a trie, but it requires exposing path
components.
So, we use a poor man's substitution -- a *vector* of sorted paths,
such that each bucket is prefix-free
closes#5246
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
Previous solution for binning paths into disjoint directories was
simple and fast -- just a single binary search.
Unfortunatelly, it wasn't coorrect: if the ditr are
/d
/d/a
/d/c
then partitioning the file /d/b/lib.rs won't pick /d as a correct
directory.
The correct solution here is a trie, but it requires exposing path
components.
So, we use a poor man's substitution -- a *vector* of sorted paths,
such that each bucket is prefix-free
closes#5246
5244: Add a command to compute memory usage statistics r=matklad a=jonas-schievink
This allows inspecting memory usage on a live rust-analyzer instance after it has been used interactively.
This will only work with `--features jemalloc`, so maybe it should print something more useful when that's not available? Right now it will just print 0 Bytes for every query.
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
5245: Refactor AssistBuilder to manage a SourceChange r=matklad a=theduke
`AssistBuilder` now managaes a full `SourceChange` instead of a
`Vec<SourceFileEdit>`.
This prepares AssistBuilder to handle creation of new files.
Co-authored-by: Christoph Herzog <chris@theduke.at>
5242: Switch to fully dynamically dispatched salsa r=matklad a=matklad
This improves compile times quite a bit
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
5234: Fix: allow for binaries from $PATH to pass validity check r=matklad a=Veetaha
Tackles https://github.com/rust-analyzer/rust-analyzer/pull/5229#issuecomment-654151387
cc @matklad @lnicola
Apparently `fs.existsSync()` works only with real paths and not with `$PATH` env var
Co-authored-by: Veetaha <veetaha2@gmail.com>
5229: Improve client logging (use output channel and more log levels) r=matklad a=Veetaha
The improvements:
* Separate output channel allows viewing the logs belonging to only our extension (without the intervention of other vscode extensions)
* All the objects in the output channel are always expanded so users only need to `Ctrl + A and Ctrl + C` to copy the entire output to send us and nothing more (e.g. currently users need to expand the object which is not obvious for them and we may lose the logs this way, see two comments: https://github.com/rust-analyzer/rust-analyzer/issues/5009#issuecomment-651361137
* More log levels allows us to be more granular in disabling only optional verbose debug-level output and leave the logs for us as developers to understand the context of user issues.
* For `log.error(...)` invocations we reveal `Rust Analyzer Client` channel automatically so that users don't have to do any additional actions to get the logs output window visible
Demo:
Co-authored-by: Veetaha <veetaha2@gmail.com>
