Treat refs to arrays the same as owned arrays in indexing_slicing and out_of_bounds_indexing

[rail-rain]

Fixes #6021

...and remove walk_ptrs_ty in favour of peel_refs, which came in 2019.

---

changelog: Fix a false positive in indexing_slicing and out_of_bounds_indexing where references to arrays weren't treated as arrays.

[rust-highfive]

r? @yaahc

(rust_highfive has picked a reviewer for you, use r? to override)

[bors]

☔ The latest upstream changes (presumably #6013) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

[bors]

☔ The latest upstream changes (presumably #5937) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

[flip1995]

@bors delegate+

r=me after rebasing (@bors r=flip1995)

TIL about peel_refs 👍

[bors]

✌️ @rail-rain can now approve this pull request

[bors]

📌 Commit c5a8b36 has been approved by flip1995)`

[bors]

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

1. git checkout fix_fp_in_indexing_slicing (switch to your branch)
2. git fetch upstream master (retrieve the latest master)
3. git rebase upstream/master -p (rebase on top of it)
4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
5. git push self fix_fp_in_indexing_slicing --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message

Auto-merging clippy_lints/src/utils/mod.rs
Auto-merging clippy_lints/src/methods/mod.rs
CONFLICT (content): Merge conflict in clippy_lints/src/methods/mod.rs
Automatic merge failed; fix conflicts and then commit the result.

[flip1995]

📌 Commit c5a8b36 has been approved by flip1995)`

Oh I thought putting it in a code block would prevent bors from triggering 🤔

[rail-rain]

Thank you for the review! By the way, bors' instruction for resolving conflicts is slightly different from what I do usually. Especially I don't put -p on the rebase command. Is that OK?

[rail-rain]

@bors r=flip1995

I've never used bors before. I hope this is what you mean ✌️.

[bors]

📌 Commit ce06472 has been approved by flip1995

[bors]

⌛ Testing commit ce06472 with merge 5af88e3...

[bors]

☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test
Approved by: flip1995
Pushing 5af88e3 to master...

[flip1995]

Especially I don't put -p on the rebase command.

Yeah same, I don't even know what -p does when rebasing. From the documentation:

-p
--preserve-merges
Recreate merge commits instead of flattening the history by replaying commits a merge commit introduces. Merge conflict resolutions or manual amendments to merge commits are not preserved.

This uses the --interactive machinery internally, but combining it with the --interactive option explicitly is generally not a good idea unless you know what you are doing (see BUGS below).

I don't think I'll use that in the future, since we usually want to prevent merge commits in PRs 🤔

I've never used bors before. I hope this is what you mean ✌️.

Perfect, thanks! 👍