7806: Fixed remaining references to `AnalysisChange` (now: `Change`) r=matklad a=regexident
(The type was renamed/moved in 8716c4cec3)
Co-authored-by: Vincent Esche <regexident@gmail.com>
7801: Restrict visibilities to the containing DefMap r=jonas-schievink a=jonas-schievink
Visibilities must always point into the DefMap where they are used, but in a block expression `self` resolves to the *containing* non-block module, which is in a different DefMap. Restrict visibilities accordingly, turning them into basically `pub(block)`, which Rust has no syntax for.
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
7797: Format generated lints and features manually r=matklad a=lnicola
As `quote` and `rustfmt` leave them on a single line, which makes running `grep` in the repository quite annoying.
Also removes a dead `gen_features.rs` file (`gen_lint_completions.rs` does the same thing).
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
7566: Add benchmark tests for mbe r=matklad a=edwin0cheng
This PR add more real world tests dumped from `rust-analyzer analysis-stats .` to benchmark its performance.
cc #7513
r? @matklad
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
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.
Closes#7604
Co-authored-by: Domantas Jadenkus <djadenkus@gmail.com>
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 <matthew@quickbeam.me.uk>
7719: De Morgan's Law assist now correctly parenthesizes binary expressions. r=Veykril a=lbrande
Closes#7694 by parenthesizing binary expressions that are negated.
Co-authored-by: lbrande <lovbra00@gmail.com>
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
