Fix iteration of destructor checker.

[keiichiw]

Don't add a type to breadcrumbs vector when it is reference, pointer, or bare functions.
Fixes #25750

The following example contains two &Sized.

fn foo() -> Option<(Box<Fn(&Sized)>, Box<Fn(&Sized)>)> {
    None
}

So &Sized appears twice as typ here.
Each time &Sized appears, walker.skip_current_subtree() should be called here in this case.
However, if &Sized is pushed to breadcrumbs at the first appearance, skip_current_subtree() will not be called at the second time.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nrc (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[nrc]

reassigning to @pnkfelix because dropck.

r? @pnkfelix

[pnkfelix]

Hmm, I'm worried this is papering over the real problem here. Namely, I would have thought that the two distinct instances of the Ty representing each occurrence of &Sized would not be considered Eq to each-other (since they have distinct inference variables for the implicit region sitting in there, i.e. &'_ Sized.

So I'm not going to immediately r+ this (but I'm not going to close the ticket either) ... I just want to take some time to investigate this myself directly, and figure out if I should be calling something other than breadcrumbs.contains in the code.

---

Update: Ah, of course; the types in question have the form for<'r> Fn(&'r S + 'r) by the time that dropck sees them, and it is stashing breadcrumbs that include the bound region 'r, even though those breadcrumbs don't make sense when we pop back out from the for <'r> ...

[pnkfelix]

closing in favor of #27236. (but thank you so much for your investigative efforts, @kw-udon )