Commit Graph

9987 Commits

Author SHA1 Message Date
Lukas Wirth
ca7cd41a48 Fix lowering trailing self paths in UseTrees 2021-02-28 23:44:49 +01:00
Lukas Wirth
9e8f4d31a4 Pickup ConstReference patterns in FindUsages 2021-02-23 23:31:53 +01:00
Jonas Schievink
338823f73a is_visible_from_def_map: handle block expressions 2021-02-23 17:56:16 +01:00
Jonas Schievink
cf456d72db Add test 2021-02-23 14:54:01 +01:00
Chetan Khilosiya
eb6cfa7f15 7526: Renamed create ssr to ide_ssr. 2021-02-23 00:59:16 +05:30
Chetan Khilosiya
e4756cb4f6 7526: Rename crate assists to ide_assists. 2021-02-23 00:59:16 +05:30
Jonas Bushart
bd525c9d20 Add isize to the list of suffixed integers in typed_integer
The missing `isize` in `typed_integers` seems to just be an oversight.

Might fix: #7751
2021-02-22 14:48:56 +01:00
Aleksey Kladov
58be1edfbb Make more common assist easier to ues 2021-02-22 16:07:08 +03:00
Laurențiu Nicola
d03cfe141c Add test from #7273 2021-02-21 19:22:14 +02:00
Laurențiu Nicola
48ae948b22 Bump deps 2021-02-21 19:13:11 +02:00
Scott McMurray
0fe44d099a Stop mixing Result and Option with ? in inline_local_variable
Depending on the discussion in RFC#3058 this might not end up being necessary, but I think it's a reasonable change regardless.
2021-02-20 14:45:30 -08:00
bors[bot]
62bc753f8b
Merge #7732
7732: Don't lower TypeBound::Lifetime as GenericPredicate::Error r=flodiebold a=Veykril

Basically we just discard the typebound for now instead when lowering to `GenericPredicate`. I think this shouldn't have any other side effects?

Fixes #7683(hopefully for real this time)

I also played around with introducing `GenericPredicate::LifetimeOutlives` and `GenericPredicate::TypeOutlives`(see b9d6904845) but that won't fix this issue(at least not for now) due to lifetime predicate mismatches when resolving methods so I figure this is a good way to fix it for now.

Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
2021-02-20 20:17:14 +00:00
Jeremy Kolb
1f3c637a1d Update tests 2021-02-20 14:59:05 -05:00
Lukas Wirth
0799288f01 Don't write trailing whitespace when formatting empty GenericPredicates 2021-02-20 20:43:04 +01:00
Lukas Wirth
9e5192d917 Don't lower TypeBound::Lifetime as GenericPredicate::Error 2021-02-20 19:08:20 +01:00
Matt Hall
8497b5bd75 Use format_to! to make logic a bit nicer 2021-02-20 17:11:04 +00:00
Matt Hall
b963893349 Fix #7712 retain visibility extracting mod to file 2021-02-20 16:51:16 +00:00
Laurențiu Nicola
4c589aded0 Remove documentation of obsolete extend selection command 2021-02-20 17:18:53 +02:00
bors[bot]
1349f6a791
Merge #7726
7726: feat(completion): add doc(hidden) completion for attributes r=lnicola a=bnjjj



Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
2021-02-20 14:18:34 +00:00
Benjamin Coenen
cf32dbd9bf feat(completion): add doc(hidden) completion for attributes
Signed-off-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
2021-02-20 15:16:05 +01:00
Benjamin Coenen
d8559588c0 fix(assist): display where predicates when we want to generate impl
Signed-off-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
2021-02-20 15:05:01 +01:00
Kirill Bulatov
4fe5786c0c Consider import prefix config settings during flyimports 2021-02-20 13:53:50 +02:00
Laurențiu Nicola
c1d37f030f Add test 2021-02-20 12:43:52 +02:00
Laurențiu Nicola
af4148970a Fix incorrect missing field diagnostic with box patterns 2021-02-20 12:36:17 +02:00
Aleksey Kladov
3db64a400c rename completion -> ide_completion
We don't have completion-related PRs in flight, so lets do it
2021-02-17 17:53:31 +03:00
Lukas Wirth
2887426da0 Revert "Replace usage of ast::NameOrNameRef with ast::NameLike"
This reverts commit e1dbf43cf8.
2021-02-17 15:00:44 +01:00
bors[bot]
4054525c41
Merge #7699
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 <lukastw97@gmail.com>
2021-02-17 13:45:27 +00:00
bors[bot]
056601b41f
Merge #7705
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 <lukastw97@gmail.com>
2021-02-17 13:17:15 +00:00
Lukas Wirth
51dda8ea8e Show hover info of the definition of ConstReference patterns instead of its type 2021-02-17 14:14:58 +01:00
Lukas Wirth
e1dbf43cf8 Replace usage of ast::NameOrNameRef with ast::NameLike 2021-02-17 14:02:34 +01:00
Michał Muskała
528a0bcf9b Avoid transmitting unchanged diagnostics
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.
2021-02-17 12:45:17 +01:00
bors[bot]
b3c848ee28
Merge #7703
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 <unratito@gmail.com>
2021-02-17 01:24:25 +00:00
bstrie
3c922072ae Remove use of deprecated std::collections::Bound 2021-02-16 18:22:14 -05:00
Paco Soberón
e0eb80eaee Allow comments between newlines in chaining hints 2021-02-17 00:09:56 +01:00
Lukas Wirth
e52bdc55ef Implement ast::AstNode for NameLike and move it to node_ext 2021-02-16 19:27:08 +01:00
bors[bot]
054caa81c5
Merge #7690
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 <regexident@gmail.com>
2021-02-16 18:24:28 +00:00
Jonas Schievink
50d18eb0a6 Use cfg(target_arch) instead of a Cargo feature
Not that WASM works right now anyways...
2021-02-16 18:50:06 +01:00
bors[bot]
c9672a0539
Merge #7657
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 <aleksey.kladov@gmail.com>
2021-02-16 16:34:22 +00:00
Aleksey Kladov
1fcf687657 Fix bitrotted module name 2021-02-16 19:17:32 +03:00
Aleksey Kladov
f3d56b89c5 Enable offset-encoding capability 2021-02-16 19:17:32 +03:00
Aleksey Kladov
c8b9ec8e62 Implement utf8 offsets 2021-02-16 19:17:32 +03:00
Aleksey Kladov
0025836f26 Make it easy to add additional context for offset conversion 2021-02-16 19:17:32 +03:00
Aleksey Kladov
95209aa3f8 Make utf8 default, implement utf16 in terms of it 2021-02-16 19:17:32 +03:00
Aleksey Kladov
00cc778c8c reduce code duplication in tests 2021-02-16 19:17:32 +03:00
Aleksey Kladov
2cb4ac9eb4 Prepare for utf-8 offsets 2021-02-16 19:17:32 +03:00
kjeremy
f9bb398cc5 Fix a few clippy::perf warnings 2021-02-16 10:55:34 -05:00
Vincent Esche
1a44168260 Split pub fn cargo_load into pub fn load_workspace_at and pub fn load_workspace 2021-02-16 16:37:52 +01:00
bors[bot]
cc49502ab4
Merge #7695
7695: Bump lsp-types r=matklad a=kjeremy

Nothing to see here...

Co-authored-by: kjeremy <kjeremy@gmail.com>
2021-02-16 14:32:33 +00:00
kjeremy
88a5e1d036 Bump lsp-types 2021-02-16 09:21:07 -05:00
bors[bot]
b7a6d830be
Merge #7687
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 <arnaud.golfouse@laposte.net>
2021-02-16 14:16:47 +00:00