aboutsummaryrefslogtreecommitdiff
path: root/editors/code/ra_syntax_tree.tmGrammar.json
diff options
context:
space:
mode:
authorbors[bot] <26634292+bors[bot]@users.noreply.github.com>2021-02-24 19:24:22 +0000
committerGitHub <[email protected]>2021-02-24 19:24:22 +0000
commitdc14c432f538656dc4c6e33693031fb62dfdcad7 (patch)
tree1b7a823d2acbc72312e38e259ed5a116d641ccac /editors/code/ra_syntax_tree.tmGrammar.json
parent0537510aef4059d5f79146a8dc2734ffdb27dc74 (diff)
parenta28e8628255198aa36bcde1f380763ef257beabd (diff)
Merge #7741
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]>
Diffstat (limited to 'editors/code/ra_syntax_tree.tmGrammar.json')
0 files changed, 0 insertions, 0 deletions