bors[bot] [Sat, 27 Feb 2021 14:29:10 +0000 (14:29 +0000)]
Merge #7677
7677: More enum matching r=yoshuawuyts a=jDomantas
* Renamed existing `generate_enum_match_method` to `generate_enum_is_variant`
* Added two similar assists to generate `into_` and `as_` methods.
* Made all of them general enough to work on record and tuple variants too.
For `as_` method generation there's room to improve:
* Right now it always returns `Option<&Field>`, even though `Option<Field>` would be nicer when `Field: Copy`. I don't know how to check if the field type implements `Copy`. If given suggestions I could try to fix this in a follow-up pr.
* `&String` could be replaced with `&str`, `&Box<_>` with `&_`, and probably some more. I don't know what would be a good way to do that.
I wonder if this tries to guess too much at the right thing here. A common pattern is:
```rust
let col = vec![1, 2, 3];
for v in &mut col {
*v *= 2;
}
// equivalent to:
col.iter_mut().for_each(|v| *v *= 2);
```
I've tried to detect this case by checking if the expression after the `in` is a (mutable) reference and if not inserting iter()/iter_mut(). This is just a convention used in the stdlib however, so could sometimes be wrong. I'd be happy to make an improvement for this, but not sure what would be best. A few options spring to mind:
1. Only allow this for types that are known to have iter/iter_mut (ie stdlib types)
2. Try to check if iter/iter_mut exists and they return the right iterator type
3. Don't try to do this and just add `.into_iter()` to whatever is after `in`
Co-authored-by: Matt Hall <matthew@quickbeam.me.uk>
bors[bot] [Sun, 21 Feb 2021 00:18:49 +0000 (00:18 +0000)]
Merge #7735
7735: Stop mixing Result and Option with ? in inline_local_variable r=Veykril a=scottmcm
Depending on the discussion in https://github.com/rust-lang/rfcs/pull/3058 this might not end up being necessary, but I think it's a reasonable change regardless.
Co-authored-by: Scott McMurray <scottmcm@users.noreply.github.com>
bors[bot] [Sat, 20 Feb 2021 20:17:14 +0000 (20:17 +0000)]
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 https://github.com/Veykril/rust-analyzer/commit/b9d69048451a5f2e9c5a72c800369bbeef36fdcf) 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.
bors[bot] [Sat, 20 Feb 2021 15:31:59 +0000 (15:31 +0000)]
Merge #7727
7727: Remove documentation of obsolete extend selection command r=matklad a=lnicola
Closes #7454
This is available in LSP as `textDocument/selectionRange` and no longer exists as a stand-alone command, so we shouldn't mention it in the manual because it's confusing (it doesn't appear in `package.json`).
bors[bot] [Sat, 20 Feb 2021 11:03:15 +0000 (11:03 +0000)]
Merge #7723
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 :).
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.
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).
projects / rust.git / log