Copying is O(n)—not the memory allocation

When encountering trait bound errors that satisfy some heuristics that
tell us that the relevant trait for the user comes from the root
obligation and not the current obligation, we use the root predicate for
the main message.

This allows to talk about "X doesn't implement Pattern<'_>" over the
most specific case that just happened to fail, like  "char doesn't
implement Fn(&mut char)" in
`tests/ui/traits/suggest-dereferences/root-obligation.rs`

The heuristics are:

 - the type of the leaf predicate is (roughly) the same as the type
   from the root predicate, as a proxy for "we care about the root"
 - the leaf trait and the root trait are different, so as to avoid
   talking about `&mut T: Trait` and instead remain talking about
   `T: Trait` instead
 - the root trait is not `Unsize`, as to avoid talking about it in
   `tests/ui/coercion/coerce-issue-49593-box-never.rs`.

```
error[E0277]: the trait bound `&char: Pattern<'_>` is not satisfied
  --> $DIR/root-obligation.rs:6:38
   |
LL |         .filter(|c| "aeiou".contains(c))
   |                             -------- ^ the trait `Fn<(char,)>` is not implemented for `&char`, which is required by `&char: Pattern<'_>`
   |                             |
   |                             required by a bound introduced by this call
   |
   = note: required for `&char` to implement `FnOnce<(char,)>`
   = note: required for `&char` to implement `Pattern<'_>`
note: required by a bound in `core::str::<impl str>::contains`
  --> $SRC_DIR/core/src/str/mod.rs:LL:COL
help: consider dereferencing here
   |
LL |         .filter(|c| "aeiou".contains(*c))
   |                                      +
```

Fix rust-lang#79359, fix rust-lang#119983, fix rust-lang#118779, cc rust-lang#118415 (the suggestion needs
to change).

… methods on non-`Iterator`

```
error[E0599]: no method named `map` found for struct `Vec<bool>` in the current scope
  --> $DIR/vec-on-unimplemented.rs:3:23
   |
LL |     vec![true, false].map(|v| !v).collect::<Vec<_>>();
   |                       ^^^ `Vec<bool>` is not an iterator
   |
help: call `.into_iter()` first
   |
LL |     vec![true, false].into_iter().map(|v| !v).collect::<Vec<_>>();
   |                       ++++++++++++
```

We used to provide some help through `rustc_on_unimplemented` on non-`impl Trait` and non-type-params, but this lets us get rid of some otherwise unnecessary conditions in the annotation on `Iterator`.

…lector and use a runtime switch instead

As this can cause panics on array accesses later.

Co-authored-by: Rémy Rakic <remy.rakic+github@gmail.com>

…c-into-inner, r=cuviper

Add an example to demonstrate how Rc::into_inner works

This PR adds an example to Rc::into_inner, since it didn't have one previously.

…y, r=cuviper

Add vector time complexity

Added time complexity for `Vec` methods `push`, `push_within_capacity`, `pop`, and `insert`.

<details>

<summary> Reference images </summary>

![`Vec::push` documentation](https://github.com/rust-lang/rust/assets/78604367/dc966bbd-e92e-45a6-af82-35afabfa79a9)

![`Vec::push_within_capacity` documentation](https://github.com/rust-lang/rust/assets/78604367/9aadaf48-46ed-4fad-bdd5-74b98a61f4bb)

![`Vec::pop` documentation](https://github.com/rust-lang/rust/assets/78604367/88ec0389-a346-4ea5-a3b7-17caf514dd8b)

![`Vec::insert` documentation](https://github.com/rust-lang/rust/assets/78604367/960c15c3-ef8e-4aa7-badc-35ce80f6f221)

</details>

I followed a convention to use `#Time complexity` that I found in [the `BinaryHeap` documentation](https://doc.rust-lang.org/std/collections/struct.BinaryHeap.html#time-complexity-1). Looking through the rest of standard library collections, there is not a consistent way to handle this.

[`Vec::swap_remove`](https://doc.rust-lang.org/std/vec/struct.Vec.html#method.swap_remove) does not have a dedicated section for time complexity but does list it.

[`VecDeque::rotate_left`](https://doc.rust-lang.org/std/collections/struct.VecDeque.html#complexity) uses a `#complexity` heading.

…viper

Clarify/add `must_use` message for Rc/Arc/Weak::into_raw.

The current `#[must_use]` messages for `{sync,rc}::Weak::into_raw` ("`self` will be dropped if the result is not used") are misleading, as `self` is consumed and will *not* be dropped.

This PR changes their `#[must_use]` message to the same as `Arc::into_raw`'s[ current `#[must_use]` message](https://github.com/rust-lang/rust/blob/d5735645753e990a72446094f703df9b5e421555/library/alloc/src/sync.rs#L1482) ("losing the pointer will leak memory"), and also adds it to `Rc::into_raw`, which is not currently `#[must_use]`.

…-lowering, r=spastorino

Adjust error `yield`/`await` lowering

Adjust the lowering of `yield`/`await` outside of their correct scopes so that we no longer make orpan HIR exprs.

Previously, `yield EXPR` would be lowered directly to `hir::TyKind::Error` (which I'll call `<error>`) which means that `EXPR` was not present in the HIR, but now we lower it to `{ EXPR; <error> }` so that `EXPR` is not orphaned.

Fixes rust-lang#121096

…r=oli-obk

Use root obligation on E0277 for some cases

When encountering trait bound errors that satisfy some heuristics that tell us that the relevant trait for the user comes from the root obligation and not the current obligation, we use the root predicate for the main message.

This allows to talk about "X doesn't implement Pattern<'_>" over the most specific case that just happened to fail, like  "char doesn't implement Fn(&mut char)" in
`tests/ui/traits/suggest-dereferences/root-obligation.rs`

The heuristics are:

 - the type of the leaf predicate is (roughly) the same as the type from the root predicate, as a proxy for "we care about the root"
 - the leaf trait and the root trait are different, so as to avoid talking about `&mut T: Trait` and instead remain talking about `T: Trait` instead
 - the root trait is not `Unsize`, as to avoid talking about it in `tests/ui/coercion/coerce-issue-49593-box-never.rs`.

```
error[E0277]: the trait bound `&char: Pattern<'_>` is not satisfied
  --> $DIR/root-obligation.rs:6:38
   |
LL |         .filter(|c| "aeiou".contains(c))
   |                             -------- ^ the trait `Fn<(char,)>` is not implemented for `&char`, which is required by `&char: Pattern<'_>`
   |                             |
   |                             required by a bound introduced by this call
   |
   = note: required for `&char` to implement `FnOnce<(char,)>`
   = note: required for `&char` to implement `Pattern<'_>`
note: required by a bound in `core::str::<impl str>::contains`
  --> $SRC_DIR/core/src/str/mod.rs:LL:COL
help: consider dereferencing here
   |
LL |         .filter(|c| "aeiou".contains(*c))
   |                                      +
```

Fix rust-lang#79359, fix rust-lang#119983, fix rust-lang#118779, cc rust-lang#118415 (the suggestion needs to change), cc rust-lang#121398 (doesn't fix the underlying issue).

…x, r=compiler-errors

Use the correct logic for nested impl trait in assoc types

Previously we accidentally continued with the TAIT visitor, which allowed more than we wanted to.

r? ```@compiler-errors```

Don't panic when waiting on poisoned queries

This fixes a bug introduced in rust-lang#119086.

… r=compiler-errors

pattern analysis: abort on arity mismatch

This is one more PR replacing panics by `Err()` aborts. I recently audited all the `unwrap()` calls, but I had forgotten about array accesses. (Again [discovered by rust-analyzer](rust-lang/rust-analyzer#16746)).

r? ```@compiler-errors```

…compiler-errors

Avoid using unnecessary queries when printing the query stack in panics

This should fix rust-lang#121974. Alternative to rust-lang#121981.

…-errors

interpret/cast: make more matches on FloatTy properly exhaustive

Actually implementing these is pretty trivial (at least once all the scalar methods are added, which happens in rust-lang#121926), but I'm staying consistent with the other f16/f128 PRs. Also adding adding all the tests to Miri would be quite a lot of work.

There's probably some way to reduce the code duplication here with more use of generics... but that's a future refactor.^^

r? ```@tgross35```