feat: introduce path_to_local_with_projections

[ada4a]

As suggested in #15268 (comment)

WIP because:

• what should be done with the now-error-pattern-less tests/ui/double_ended_iterator_last_unfixable.rs?
• is the change in behaviour of double_ended_iterator_last okay in general?
  • cc @samueltardieu because this changes the code you added in .last() to .next_back() requires a mutable receiver #14140

changelog: none

r? @y21

[samueltardieu]

Won't those changes make double_ended_iterator_last and filter_next lint new cases? Shouldn't there be new tests to account for this?

[ada4a]

double_ended_iterator_last

Yes, but the no-longer-unfixable test case does pretty much that -- it checks that the suggestion goes through a field (in this case, tuple element) projection. I tried modifying the test case to test indexing projection as well:

let v = vec![S("four"), S("five"), S("six")];
- let v = (DropDeIterator(v.into_iter()), 42);
+ let v = [(DropDeIterator(v.into_iter()), 42)];
- println!("Last element is {}", v.0.last().unwrap().0);
+ println!("Last element is {}", v[0].0.last().unwrap().0);
//~^ ERROR: called `Iterator::last` on a `DoubleEndedIterator`

But that broke because one can't move out of an array by indexing, which last requires since it consumes the iterator.

filter_next

I think not, because the function that the lint used previously is identical to the new path_to_local_with_projections, so no new cases will be detected

[y21]

Looks good to me, I agree that the tests are sufficient. In eager_transmute/filter_next there's no behavioral change since it's the same function just factored out and double_ended_iterator_last indeed already has a test that exercises this change, like you said 👍

Could you squash?

[ada4a]

squashed (and rebased)