| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7723: Fix typos r=lnicola a=azzamsa
I have checked all the documents inside `docs/` using `grammarly.com`.
There are many suggestions in each document (some of them are false positive). I choose to fix the typos only to avoid lengthy grammar discussions. I would like to suggest to the maintainers to take a look. It is worth it.
IMHO, it better to put the article into `grammarly.com` or `languagetool.org` before pushing :).
Co-authored-by: azzamsa <[email protected]>
|
| | | | |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | | |
7722: Fix incorrect missing field diagnostic with box patterns r=Veykril a=lnicola
Closes #7711
Co-authored-by: Laurențiu Nicola <[email protected]>
|
| | | | |
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7707: rename completion -> ide_completion r=matklad a=matklad
bors r+
🤖
Co-authored-by: Aleksey Kladov <[email protected]>
|
| |/ /
| |
| |
| | |
We don't have completion-related PRs in flight, so lets do it
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7706: Revert "Replace usage of ast::NameOrNameRef with ast::NameLike" r=Veykril a=Veykril
This reverts commit e1dbf43cf85f84c3a7e40f9731fc1f7ac96f8979.
Co-authored-by: Lukas Wirth <[email protected]>
|
| |/ /
| |
| |
| | |
This reverts commit e1dbf43cf85f84c3a7e40f9731fc1f7ac96f8979.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7699: Implement ast::AstNode for NameLike and move it to node_ext r=matklad a=Veykril
With this `search`(and 2 other modules) don't necessarily go through 3 calls of `find_node_at_offset_with_descend` to find the correct node. Also makes the code that searches for NameLikes a bit easier on the eyes imo, though that can be fixed with just a helper function as well so its not that relevant.
Co-authored-by: Lukas Wirth <[email protected]>
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7705: Show hover info of the definition of ConstReference patterns instead of its type r=Veykril a=Veykril
Closes #7671
bors r+
Co-authored-by: Lukas Wirth <[email protected]>
|
| | |/ / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7704: Avoid transmitting unchanged diagnostics r=matklad a=michalmuskala
Reading through the code for diagnostics and observing debug logs, I noticed
that diagnostics are transmitted after every change for every opened file,
even if they haven't changed (especially visible for files with no diagnostics).
This change avoids marking files as "changed" if diagnostics are the same to what
was already sent before. This will only work if diagnostics are always produced in
the same order, but from my limited testing it seems this is the case.
Co-authored-by: Michał Muskała <[email protected]>
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Reading through the code for diagnostics and observing debug logs, I noticed
that diagnostics are transmitted after every change for every opened file,
even if they haven't changed (especially visible for files with no diagnostics).
This change avoids marking files as "changed" if diagnostics are the same to what
was already sent before. This will only work if diagnostics are always produced in
the same order, but from my limited testing it seems this is the case.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7701: Remove semantic tokens workaround r=SomeoneToIgnore a=kjeremy
Let's try this again.
Co-authored-by: kjeremy <[email protected]>
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
https://github.com/microsoft/vscode-languageserver-node/issues/576 has been closed with
the latest vscode-languageclient release.
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
7703: Allow comments between newlines in chaining hints r=Veykril a=unratito
Currently, chaining hints are not generated if there are comments between newlines, which is a very common pattern:
```rust
let vec = (0..10)
// Multiply by 2
.map(|x| x * 2)
// Add 3
.map(|x| x + 3)
.collect::<Vec<i32>>();
```
Besides, it seems a bit weird that this piece of code generates a chaining hint:
```rust
let vec = (0..10)
.collect::<Vec<i32>>();
```
But this one doesn't:
```rust
let vec = (0..10)
// This is a comment
.collect::<Vec<i32>>();
```
Co-authored-by: Paco Soberón <[email protected]>
|
| | |/ / / |
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7702: Remove use of deprecated `std::collections::Bound` r=Veykril a=bstrie
`std::collections::Bound` has been deprecated since Rust 1.26, but due to a bug (https://github.com/rust-lang/rust/issues/82080) it never triggered a visible deprecation warning. Fixing this is being done in https://github.com/rust-lang/rust/pull/82122 , but landing that requires rustc-analyzer to build without triggering any deprecation warnings (https://github.com/rust-lang-ci/rust/runs/1911884006#step:24:19361).
Co-authored-by: bstrie <[email protected]>
|
| |/ / / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7700: Use npm 7.x package-lock.json r=lnicola a=kjeremy
Supposedly backwards compatible
Co-authored-by: kjeremy <[email protected]>
|
| |/ / / |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7690: Extract `fn load_workspace(…)` from `fn load_cargo(…)` r=matklad a=regexident
Unfortunately in https://github.com/rust-analyzer/rust-analyzer/pull/7595 I forgot to `pub use` (rather than just `use`) the newly introduced `LoadCargoConfig`.
So this PR fixes this now.
It also:
- splits up `fn load_cargo` into a "workspace loading" and a "project loading" phase
- adds a `progress: &dyn Fn(String)` to allow third-parties to provide CLI progress updates, too
The motivation behind both of these is the fact that rust-analyzer currently does not support caching.
As such any third-party making use of `ra_ap_…` needs to providing a caching layer itself.
Unlike for rust-analyzer itself however a common use-pattern of third-parties is to analyze a specific target (`--lib`/`--bin <BIN>`/…) from a specific package (`--package`). The targets/packages of a crate can be obtained via `ProjectWorkspace::load(…)`, which currently is performed inside of `fn load_cargo`, effectively making the returned `ProjectWorkspace` inaccessible to the outer caller. With this information one can then provide early error handling via CLI (in case of ambiguities or invalid arguments, etc), instead of `fn load_cargo` failing with a possibly obscure error message. It also allows for annotating the persisted caches with its specific associated package/target selector and short-circuit quickly if a matching cache is found on disk, significantly cutting load times.
Before:
```rust
pub struct LoadCargoConfig {
pub cargo_config: &CargoConfig,
pub load_out_dirs_from_check: bool,
pub with_proc_macro: bool,
}
pub fn load_cargo(
root: &Path,
config: &LoadCargoConfig
) -> Result<(AnalysisHost, vfs::Vfs)> {
// ...
}
```
After:
```rust
pub fn load_workspace(
root: &Path,
config: &CargoConfig,
progress: &dyn Fn(String),
) -> Result<ProjectWorkspace> {
// ...
}
pub struct LoadCargoConfig {
pub load_out_dirs_from_check: bool,
pub with_proc_macro: bool,
}
pub fn load_cargo(
ws: ProjectWorkspace,
config: &LoadCargoConfig,
progress: &dyn Fn(String),
) -> Result<(AnalysisHost, vfs::Vfs)> {
// ...
}
```
Co-authored-by: Vincent Esche <[email protected]>
|
| | | |
| | |
| | |
| | | |
load_workspace`
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7697: Use `cfg(target_arch)` instead of a Cargo feature r=jonas-schievink a=jonas-schievink
Not that WASM works right now anyways...
bors r+
Co-authored-by: Jonas Schievink <[email protected]>
|
| |/ / /
| | |
| | |
| | | |
Not that WASM works right now anyways...
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7657: utf8 r=matklad a=matklad
- Prepare for utf-8 offsets
- reduce code duplication in tests
- Make utf8 default, implement utf16 in terms of it
- Make it easy to add additional context for offset conversion
- Implement utf8 offsets
closes #7453
Co-authored-by: Aleksey Kladov <[email protected]>
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | |/ / |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | | |
7696: Fix a few clippy::perf warnings r=kjeremy a=kjeremy
Co-authored-by: kjeremy <[email protected]>
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7695: Bump lsp-types r=matklad a=kjeremy
Nothing to see here...
Co-authored-by: kjeremy <[email protected]>
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7687: Specialization for async traits r=matklad a=arnaudgolfouse
Fixes #7669.
Adapting the parser seemed to be all that was needed, but I am not very experienced with the codebase. Is this enough ?
Co-authored-by: Arnaud <[email protected]>
|
| | |/ / |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7620: Support control flow in `extract_function` assist r=matklad a=cpud36
Support `return`ing from outer function, `break`ing and `continue`ing outer loops when extracting function.
# Example
Transforms
```rust
fn foo() -> i32 {
let items = [1,2,3];
let mut sum = 0;
for &item in items {
<|>if item == 42 {
break;
}<|>
sum += item;
}
sum
}
```
Into
```rust
fn foo() -> i32 {
let items = [1,2,3];
let mut sum = 0;
for &item in items {
if fun_name(item) {
break;
}
sum += item;
}
sum
}
fn fun_name(item: i32) -> bool {
if item == 42 {
return true;
}
false
}
```
# Features
Supported variants
- break and function does not return => uses `bool` and plain if
- break and function does return => uses `Option<T>` and matches on it
- break with value and function does not return => uses `Option<T>` and if let
- break with value and function does return => uses `Result<T, U>` and matches on t
- same for `return` and `continue`(but we can't continue with value)
Assist does handle nested loops and nested items(like functions, modules, impls)
Try `expr?` operator is allowed together with `return Err(_)` and `return None`.
`return expr` is not allowed.
# Not supported
## Mixing `return` with `break` or `continue`
If we have e.g. a `return` and a `break` in the selected code, it is unclear what the produced code should look like.
We can try `Result<T, Option<U>>` or something like that, but it isn't idiomatic, nor it is established. Otherwise, implementation
is relatively simple.
## `break` with label
Not sure how to handle different labels for multiple `break`s.
[edit] implemented try `expr?`
Co-authored-by: Vladyslav Katasonov <[email protected]>
|
| | | |
| | |
| | |
| | | |
Used to get E parameter from `Result<T, E>`
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
This simplifies api as we are not duplicating code from syntax crate
|
