| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| |_|/ /
|/| | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
|\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
7741: Add convert_for_to_iter_for_each assist r=mattyhall a=mattyhall
Implements one direction of #7681
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 <[email protected]>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* Use known names for iter/iter_mut method (simplifies checking if the
method exists
* Extract code to check assist with fixtures to function
|
| | | |
| | | |
| | | |
| | | |
| | | | |
* Move code to build replacement into closure
* Look for iter/iter_mut methods on types behind reference
|
| |/ / |
|
| | | |
|
| | | |
|
| |/
|/| |
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
The missing `isize` in `typed_integers` seems to just be an oversight.
Might fix: #7751
|
| |
|
| |
|
| |
|
|
|
|
| |
Depending on the discussion in RFC#3058 this might not end up being necessary, but I think it's a reasonable change regardless.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
Co-authored-by: Lukas Wirth <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
7726: feat(completion): add doc(hidden) completion for attributes r=lnicola a=bnjjj
Co-authored-by: Benjamin Coenen <[email protected]>
|
| |/
| |
| |
| | |
Signed-off-by: Benjamin Coenen <[email protected]>
|
|/
|
|
| |
Signed-off-by: Benjamin Coenen <[email protected]>
|
| |
|
| |
|
| |
|
|
|
|
| |
We don't have completion-related PRs in flight, so lets do it
|
|
|
|
| |
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]>
|
| |/ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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]>
|
| | | |
|
|/ / |
|