aboutsummaryrefslogtreecommitdiff
path: root/crates/ide_assists/src/tests
Commit message (Collapse)AuthorAgeFilesLines
* Use consistent naming for assistAleksey Kladov2021-02-281-23/+23
|
* generate try_into instead of intoDomantas Jadenkus2021-02-271-29/+29
|
* add generate_enum_as_method assistDomantas Jadenkus2021-02-271-0/+29
|
* add generate_enum_into_method assistDomantas Jadenkus2021-02-271-0/+29
|
* rename existing assist to generate_enum_is_methodDomantas Jadenkus2021-02-271-2/+2
|
* Merge #7741bors[bot]2021-02-241-0/+23
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
| * Add convert_for_to_iter_for_each assistMatt Hall2021-02-231-0/+23
| |
* | De Morgan's Law assist now correctly inverts <, <=, >, >=.lbrande2021-02-241-2/+2
| |
* | De Morgan's Law assist now correctly parenthesizes binary expressions.lbrande2021-02-241-2/+2
|/
* 7526: Rename crate assists to ide_assists.Chetan Khilosiya2021-02-221-0/+1329