bors[bot] [Wed, 17 Feb 2021 13:45:27 +0000 (13:45 +0000)]
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.
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 <michal@muskala.eu>
Michał Muskała [Wed, 17 Feb 2021 11:38:11 +0000 (12:38 +0100)]
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.
bors[bot] [Wed, 17 Feb 2021 01:02:21 +0000 (01:02 +0000)]
Merge #7702
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).
bors[bot] [Tue, 16 Feb 2021 18:24:28 +0000 (18:24 +0000)]
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.
bors[bot] [Tue, 16 Feb 2021 16:34:22 +0000 (16:34 +0000)]
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
bors[bot] [Tue, 16 Feb 2021 14:01:09 +0000 (14:01 +0000)]
Merge #7620
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
}
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.
Sorry for missing this one in original PR. This was an issue before https://github.com/rust-analyzer/rust-analyzer/pull/7596/commits/ee049b256a7718fb346a7172a34f0fc324b3269b, and I fixed it, yet *somehow* order got reversed (to a logical one)
bors[bot] [Sun, 14 Feb 2021 16:17:03 +0000 (16:17 +0000)]
Merge #7656
7656: Implement constructor usage search for almost all items r=matklad a=Veykril
This PR moves the filering for enum constructors to the HIR, with this unprefixed variants as well as when the enum has been renamed via use will then still show up properly.
We now walk the ast of the `NameRef` up until we find a `PathExpr`(which also handles `CallExpr` for tuple-type structs and variants already) or a `RecordExpr`. For enum search we then take the `path` out of that expression and do a resolution on it to compare it with the definition enum.
With this PR we now support searching for all constructor literals, Unit-, Tuple- and Record-Structs, Unit-, Tuple- and Record-Variants as well as Unions.
There is one shortcoming due to how the search is triggered. Unit Variants constructors can't be searched as we have no position for it to kick off the search(since a comma doesn't have to exist for the last variant).
Closes #2549 though it doesn't implement it as outlined in the issue since the reference kind was removed recently, though I believe the approach taken here is better personally.
bors[bot] [Sun, 14 Feb 2021 15:42:07 +0000 (15:42 +0000)]
Merge #7643 #7663
7643: Automatically detect the rustc-src directory (fixes #3517) r=matklad a=bnjbvr
If the configured rustcSource was not set, then try to automatically
detect a source for the sysroot rustc directory.
I wasn't sure how to do it in the case of the project.json file, though.
7663: Tolerate spaces in nix binary patching r=matklad a=CertainLach
If path to original file contains space (I.e on code insiders, where
default data directory is ~/Code - Insiders/), then there is syntax
error evaluating src arg.
Instead pass path as str, and coerce to path back in nix expression
Co-authored-by: Benjamin Bouvier <public@benj.me> Co-authored-by: Yaroslav Bolyukin <iam@lach.pw>
bors[bot] [Sun, 14 Feb 2021 15:29:00 +0000 (15:29 +0000)]
Merge #7668
7668: Finalize rename infra rewrite r=matklad a=Veykril
This should be the final PR in regards to rewriting rename stuff, #4290.
It addresses 3 things:
- Currently renaming import aliases causes some undesired behavior(see #5198) which is why this PR causes us to just return an error if an attempt at renaming an alias is made for the time being. Though this only prevents it from happening when the alias import is renamed, so its not too helpful.
- Fixes #6898
- If we are inside a macro file simply rename the input name node as there isn't really a way to do any of the fancy shorthand renames and similar things as for that we would have to exactly know what the macro generates and what not.
bors[bot] [Sat, 13 Feb 2021 21:37:35 +0000 (21:37 +0000)]
Merge #7664
7664: refactor impl generation in assists r=Veykril a=jDomantas
Follow-up to #7659: all impl generation in assists (at least what I found) is now done through `utils::{generate_impl_text, generate_trait_impl_text}`.
If path to original file contains space (I.e on code insiders, where
default data directory is ~/Code - Insiders/), then there is syntax
error evaluating src arg.
Instead pass path as str, and coerce to path back in nix expression
bors[bot] [Sat, 13 Feb 2021 15:56:17 +0000 (15:56 +0000)]
Merge #7659
7659: Improve "Generate From impl" r=Veykril a=jDomantas
* Allows any field type. Previously it was restricted to path types, but I don't see why it couldn't apply to all other types too. (the main reason for is PR is that I'm too lazy to write out `From<&'static str>` by hand 😄)
* More correct handling for generic enums - previously it wouldn't emit generic params on the impl.
* Also accepts variants with named field.
The impl generation code got mostly copy-pasted from generate_impl assist - please tell if there's an easy way to avoid this duplication.
Lukas Wirth [Fri, 12 Feb 2021 20:30:55 +0000 (21:30 +0100)]
Implement constructor usage search for almost all items
For all struct kinds, unions and enums, as well as for record- and
tuple-variants but not for unit-variants, as these have no trailing
character we can anchor the search to. Functionality wise it is
implemented though.
bors[bot] [Fri, 12 Feb 2021 18:01:36 +0000 (18:01 +0000)]
Merge #7358
7358: Refactor reference searching to work with the ast r=matklad a=Veykril
Addresses #4290
This PR is still a bit unpolished. Its main purpose for now is to discuss the direction of the changes as to whether this seems to be the right approach or not. I annotated a few parts with reviews to give a better overwiew without having to read into it too much.
Big part of the diff are test output changes in the `references` module.
Fixes #7605. This makes it so assists can use helpers to either append a method to the start or the end of an `impl` block. Thanks!
@Veykril if this is merged, perhaps it could be good to update the gif in https://github.com/rust-analyzer/rust-analyzer/pull/7617#issuecomment-776622135 ? -- this should fix the ordering issue when generating multiple methods.