This enables LLVM to optimize this function as if it was strlen
without having to enable std-aware LTO.

I think this was simply forgotten in rust-lang#113464.

this previously was a off-by-one error.

…estions, r=workingjubilee

Add `suggestion` for some `#[deprecated]` items

Consider code:
```rust
fn main() {
    let _ = ["a", "b"].connect(" ");
}
```

Currently it shows deprecated warning:
```rust
warning: use of deprecated method `std::slice::<impl [T]>::connect`: renamed to join
 --> src/main.rs:2:24
  |
2 |     let _ = ["a", "b"].connect(" ");
  |                        ^^^^^^^
  |
  = note: `#[warn(deprecated)]` on by default
```

This PR adds `suggestion` for `connect` and some other deprecated items, so the warning will be changed to this:
```rust
warning: use of deprecated method `std::slice::<impl [T]>::connect`: renamed to join
 --> src/main.rs:2:24
  |
2 |     let _ = ["a", "b"].connect(" ");
  |                        ^^^^^^^
  |
  = note: `#[warn(deprecated)]` on by default
help: replace the use of the deprecated method
  |
2 |     let _ = ["a", "b"].join(" ");
  |                        ^^^^
```

…=thomcc

Increase clarity about Hash - Eq consistency in HashMap and HashSet docs

As discussed [here](https://users.rust-lang.org/t/what-hapens-if-hash-and-partialeq-dont-match-when-using-hashmap/98052/13) the description of logic errors in `HashMap` and `HashSet` does not explicitly apply to
```text
k1 == k2 -> hash(k1) == hash(k2)
```
but this is likely what is intended.

This PR is a small doc change to correct this.

r? rust-lang/libs

…ompiler-errors

instantiate response: no unnecessary new universe

this previously was a off-by-one error.

fixes rust-lang/trait-system-refactor-initiative#55

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

Inline strlen_rt in CStr::from_ptr

This enables LLVM to optimize this function as if it was strlen (LLVM knows what it does, and can avoid calling it in certain situations) without having to enable std-aware LTO. This is essentially doing what rust-lang#90007 did, except updated for this function being `const`.

Pretty sure it's safe to roll-up, considering last time I did make this change it didn't affect performance (`CStr::from_ptr` isn't really used all that often in Rust code that is checked by rust-perf).

…anieu

Expose core::error::request_value in std

I think this was simply forgotten in rust-lang#113464.

/cc `@waynr`

r? `@Amanieu`

Usage zero as language id for `FormatMessageW()`

This switches the language selection from using system language (note that this might be different than application language, typically stored as thread ui language) to use `FormatMessageW` default search strategy, which is `neutral` first, then `thread ui lang`, then `user language`, then `system language`, then `English`. (See https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-formatmessagew)

This allows the Rust program to take more control of `std::io::Error`'s message field, by setting up thread ui language themselves before hand (which many programs already do).

remove redundant var rebindings