| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| | |
Fix audit caching better
|
| | |
|
|\|
| |
| | |
Fix cargo audit caching
|
|/
|
|
|
|
| |
See
https://github.com/actions/cache/issues/133#issuecomment-599102035
for chown bit
|
|\
| |
| | |
Cache cargo-audit on CI
|
| |
| |
| |
| | |
In bash, && and || have the same priority.
|
| |
| |
| |
| | |
closes #3399
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
3584: Switch to dynamic dispatch r=matklad a=matklad
Benches are in https://github.com/rust-analyzer/rust-analyzer/issues/1987#issuecomment-598807185
TL;DR:
* 33% faster release build
* slightly worse/same perf
* no changes for debug build
* slightly smaller binary
cc @flodiebold I genuinely don't know if it is a good idea or not.
Co-authored-by: Aleksey Kladov <[email protected]>
|
|/
|
|
|
|
|
| |
It improves compile time in `--release` mode quite a bit, it doesn't
really slow things down and, conceptually, it seems closer to what we
want the physical architecture to look like (we don't want to
monomorphise EVERYTHING in a single leaf crate).
|
|\
| |
| | |
Add installation notes for Arch Linux users
|
| | |
|
| | |
|
|\ \
| |/
|/| |
Retry rust audit as well
|
|/
|
|
| |
https://github.com/rust-analyzer/rust-analyzer/runs/511553989?check_suite_focus=true#step:3:6
|
|\
| |
| |
| |
| |
| |
| |
| | |
3604: Remove dat fixme r=matklad a=Veetaha
Cleanup as per #3603
Co-authored-by: Veetaha <[email protected]>
|
| | |
|
|\ \
| | |
| | | |
Make audit more reliable
|
| | |
| | |
| | |
| | |
| | |
| | | |
I've seen this transient error a couple of times:
https://github.com/rust-analyzer/rust-analyzer/runs/511162809?check_suite_focus=true#step:5:8
|
|/ / |
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
3573: Check all crates of the workspace r=matklad a=matklad
Previously, if the root of the was was a real crate, only this crate
was checked.
Ideally, we might want some kind of config here (which might be just
overriding the whole command), but `--workspace` is def a nicer
default.
r? @kiljacken
Co-authored-by: Aleksey Kladov <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, if the root of the was was a real crate, only this crate
was checked.
Ideally, we might want some kind of config here (which might be just
overriding the whole command), but `--workspace` is def a nicer
default.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
3587: Use WorkDoneProgress LSP API for initial load r=matklad a=slyngbaek
Addresses #3283
Rather than using custom UI for showing the loaded state. Rely
on the WorkDoneProgress API in 3.15.0
https://microsoft.github.io/language-server-protocol/specification#workDoneProgress.
No client-side work was necessary. The UI is not exactly what is
described in the issue but afaict that's how VS Code implements the LSP
API.
- The WorkDoneProgressEnd does not appear to display its message
contents (controlled by vscode)
Co-authored-by: Steffen Lyngbaek <[email protected]>
|
| | | |
|
| | |
| | |
| | |
| | | |
- Handle case of no projects. The notification still needs to be posted
|
| | | |
|
| | |
| | |
| | |
| | | |
- Properly wait for workspace loading to be done
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Addresses #3283
Rather than using custom UI for showing the loaded state. Rely
on the WorkDoneProgress API in 3.15.0
https://microsoft.github.io/language-server-protocol/specification#workDoneProgress.
No client-side work was necessary. The UI is not exactly what is
described in the issue but afaict that's how VS Code implements the LSP
API.
- The WorkDoneProgressEnd does not appear to display its message
contents (controlled by vscode)
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
3603: Fix crate display name dashes r=matklad a=SomeoneToIgnore
A follow-up of https://github.com/rust-analyzer/rust-analyzer/pull/3602#discussion_r392733525
Co-authored-by: Kirill Bulatov <[email protected]>
|
| | | | |
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
3534: Feature: vscode impl nightlies download and installation r=Veetaha a=Veetaha
I need to test things more, but the core shape of the code is quite well-formed.
The main problem is that we save the release date only for nightlies and there are no means to get the release date of the stable extension (i.e. for this we would need to consult the github releases via a network request, or we would need to somehow save this info into package.json or any other file accessible from the extension code during the deployment step, but this will be very hard I guess).
So there is an invariant that the users can install nightly only from our extension and they can't do it manually, because when installing the nightly `.vsix` we actually save its release date to `globalState`
Closes: #3402
TODO:
- [x] More manual tests and documentation
cc @matklad @lnicola
Co-authored-by: Veetaha <[email protected]>
Co-authored-by: Veetaha <[email protected]>
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|