make [manual_map] ignore types that contain dyn

[J-ZhengLi]

fixes: #12659

[manual_map] and [manual_filter] shares the same check logic, but this issue doesn't seems like it could affect manual_filter (?)

---

changelog: make [manual_map] ignore types that contain dyn

[rustbot]

r? @dswij

rustbot has assigned @dswij.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[J-ZhengLi]

@rustbot ready

[xFrednet]

Hey, this is a ping from triage. @dswij can you give this PR a review? It's totally fine if you don't have the time right now, you can reassign the PR to a random team member using r? clippy.

@rustbot ready

[Alexendoo]

I'll take this one since I looked into it previously, r? me

[rustbot]

Failed to set assignee to me: invalid assignee

Note: Only org members with at least the repository "read" role, users with write permissions, or people who have commented on the PR may be assigned.

[J-ZhengLi]

I need more time on this

@rustbot author

[Alexendoo]

Is this to catch something specific? It could lead to some FPs though it might be fairly rare

[J-ZhengLi]

hmmm, I forgot why I left it there, but... you're right 😂

[J-ZhengLi]

Oh I think I got it, it was a lazy solution to pass this test:

match Some(0) {
    Some(x) => Some(vec![x]),
     None => None,
};
// ^ help: try: `Some(0).map(|x| vec![x])`

The coercion in this case is totally irrelevant, but I don't know how to filter it out

[J-ZhengLi]

Ok, so... I think I know where the problem was.

technically, the above case is not a coercion site(?) according to the coercion doc:

...these are typically places where the desired type is explicit or can be derived by propagation from explicit types (without type inference).

Thus using map here actually works. However, because I have a type adjustment check at first, which causing it to return early as soon as any expr's ty was adjusted (and this expr in vec! was indeed adjusted), causing FN on the above test case.

Ignore what I said earlier that it was totally irrelevant, here is a counter example which might not seems rare at all:

let x: Option<Vec<&[u8]>> = match Some(()) {
    Some(_) => Some(vec![b"1234"]),
    None => None,
};

With that from_expansion check, this will surely cause FP, so it's definitely a "no". And I also need the type adjustment check, otherwise this counter example wouldn't work.

Now I'm out of options, do I need to bring back the expr_has_explicit_ty function from the beginning?

[bors]

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

[Alexendoo]

Sorry for the delay! Looks ready to merge with conflicts fixed

[J-ZhengLi]

Sorry for the delay! Looks ready to merge with conflicts fixed

rebased, thank you for all the help and guidance~

[J-ZhengLi]

@rustbot ready

[Alexendoo]

Sorry again took a break around Christmas, I'll merge it for real this time after a rebase for the conflict + new merge group stuff

[J-ZhengLi]

Sorry again took a break around Christmas, I'll merge it for real this time after a rebase for the conflict + new merge group stuff

It's alright, I'll make sure to ping you this time lol 😄

(here it come~) @Alexendoo

[Alexendoo]

Thanks!