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`.

With rust 1.75 the absolute build path is embedding into '.rustc' section and which causes reproducibility issues. Detailed issue is here.
rust-lang#120825 (comment)

With this change the 'absolute path' changed back to '/rust/$hash' format.

Most of this method's arguments are usually or always forwarded as-is to
recursive invocations.

Wrapping them in a dedicated struct allows us to document each struct field,
and lets us use struct-update syntax to indicate which arguments are being
modified when making a recursive call.

This test won't work on windows 7, as the Thread::set_name function is
not implemented there (win7 does not provide a documented mechanism to
set thread names).

…r=lcnr

constify a couple thread_local statics

Convert the rest of the visitors to use `VisitorResult`

Continuing from rust-lang#121256.

…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).

Extract an arguments struct for `Builder::then_else_break`

Most of this method's arguments are usually or always forwarded as-is to recursive invocations.

Wrapping them in a dedicated struct allows us to document each struct field, and lets us use struct-update syntax to indicate which arguments are being modified when making a recursive call.

---

While trying to understand the lowering of `if` expressions, I found it difficult to keep track of the half-dozen arguments passed through to every call to `then_else_break`. I tried switching over to an arguments struct, and I found that it really helps to make sense of what each argument does, and how each call is modifying the arguments.

I have some further ideas for how to streamline these recursive calls, but I've kept those out of this PR so that it's a pure refactoring with no behavioural changes.

…t, r=pnkfelix

Fix redundant import errors for preload extern crate

Fixes rust-lang#121915

Removing absolute path in proc-macro

With rust 1.75 the absolute build path name is embedding into proc-macro (.rustc section) and which causes reproducibility issues.
Detailed issue description is here - rust-lang#120825 (comment)

With this change the 'absolute path' changed back to '/rust/$hash' format as in earlier revisions.

Don't run test_get_os_named_thread on win7

This test won't work on windows 7, as the Thread::set_name function is not implemented there (win7 does not provide a documented mechanism to set thread names).

Doc: Fix incorrect reference to integer in Atomic{Ptr,Bool}::as_ptr.

I am assuming "resulting integer" is an error, since we are talking about pointers and booleans here. Seems like it was missed while copy & pasting the docs from the integer versions. I also checked the rest of the docs, and this was the only mention of integers.

…th, r=bjorn3

Fix duplicated path in the "not found dylib" error

While working on the gcc backend, I couldn't figure out why I had this error:

```
error: couldn't load codegen backend /checkout/compiler/rustc_codegen_gcc/target/release/librustc_codegen_gcc.so/checkout/compiler/rustc_codegen_gcc/target/release/librustc_codegen_gcc.so: cannot open shared object file: No such file or directory
```

As you can see, the path is duplicated for some reason. After investigating a bit more, I realized that `libloading::Error::LoadLibraryExW` starts with the path of the not found dylib, making it appear twice in our error afterward (because we do render it like this: `{path}{err}`, and since the `err` starts with the path...).

Thanks to `@bjorn3` for linking me to rust-lang#121392. :)