Auto merge of #11135 - smoelius:unwrap_or_else_default-fp, r=Centri3

Fix `unwrap_or_else_default` false positive

This PR fixes a false positive in the handling of `unwrap_or_else` with a default value when the value is needed for type inference.

An easy example to exhibit the false positive is the following:
```rust
    let option = None;
    option.unwrap_or_else(Vec::new).push(1);
```
The following code would not compile, because the fact that the value is a `Vec` has been lost:
```rust
    let option = None;
    option.unwrap_or_default().push(1);
```
The fix is to:
- implement a heuristic to tell whether an expression's type can be determined purely from its subexpressions, and the arguments and locals they use;
- apply the heuristic to `unwrap_or_else`'s receiver.

The heuristic returns false when applied to `option` in the above example, but it returns true when applied to `option` in either of the following examples:
```rust
    let option: Option<Vec<u64>> = None;
    option.unwrap_or_else(Vec::new).push(1);
```
```rust
    let option = None::<Vec<u64>>;
    option.unwrap_or_else(Vec::new).push(1);
```

(Aside: https://github.com/rust-lang/rust-clippy/pull/10120 unfairly contained multiple changes in one PR. I am trying to break that PR up into smaller pieces.)

---

changelog: FP: [`unwrap_or_else_default`]: No longer lints if the default value is needed for type inference

0 files changed, 0 insertions, 0 deletions