As indicated in the comment, the BigNum::bit_length function could be
optimized by using CLZ, which is often a single instruction instead a
loop.

I think the code is also simpler now without the loop.

I added some additional tests for Big8x3 and Big32x40 to ensure that
there were no regressions.

Thank you to @scottmcm for suggesting the handy `log2()` function.

Rust currently identifies as MASM (Microsoft Assembler) in the PDB
debug info format on Windows because no identifier was available.

This change pulls in a cherry-pick to Rust's LLVM that includes the
change to use the new identifier for Rust.

https://docs.microsoft.com/en-us/visualstudio/debugger/debug-interface-access/cv-cfl-lang

`@m-ou-se` [realized][1] that because `Read` is implemented for `&mut impl
Read`, there's no need to take `&mut` in `io::read_to_string`.

Removing the `&mut` from the signature allows users to remove the `&mut`
from their calls (and thus pass an owned reader) if they don't use the
reader later.

[1]: rust-lang#80218 (comment)

Currently all generators are named with a `generator$N` suffix,
regardless of where they come from. This means an `async fn` shows up as
a generator in stack traces, which can be surprising to async
programmers since they should not need to know that async functions are
implementated using generators.

This change generators a different name depending on the generator kind,
allowing us to tell whether the generator is the result of an async
block, an async closure, an async fn, or a plain generator.

…ion, r=scottmcm

Simplification of BigNum::bit_length

As indicated in the comment, the BigNum::bit_length function could be
optimized by using CLZ, which is often a single instruction instead a
loop.

I think the code is also simpler now without the loop.

I added some additional tests for Big8x3 and Big32x40 to ensure that
there were no regressions.

Use the new language identifier for Rust in the PDB debug format

Rust currently identifies as MASM (Microsoft Assembler) in the PDB
debug info format on Windows because no identifier was available.

This change pulls in a cherry-pick to Rust's LLVM that includes the
change to use the new identifier for Rust.

https://docs.microsoft.com/en-us/visualstudio/debugger/debug-interface-access/cv-cfl-lang

Inline std::os::unix::ffi::OsStringExt methods

Those methods essentially do nothing at assembly level. On Unix systems, `OsString` is represented as a `Vec` without performing any transformations.

…ou-se

Remove `&mut` from `io::read_to_string` signature

``@m-ou-se`` [realized][1] that because `Read` is implemented for `&mut impl
Read`, there's no need to take `&mut` in `io::read_to_string`.

Removing the `&mut` from the signature allows users to remove the `&mut`
from their calls (and thus pass an owned reader) if they don't use the
reader later.

r? `@m-ou-se`

[1]: rust-lang#80218 (comment)

…=nikomatsakis

Ignore static lifetimes for GATs outlives lint

cc rust-lang#87479 (comment)

Also included a bit of cleanup of `ty_known_to_outlive` and `region_known_to_outlive`

r? `@nikomatsakis`

Generate more precise generator names

Currently all generators are named with a `generator$N` suffix, regardless of where they come from. This means an `async fn` shows up as a generator in stack traces, which can be surprising to async programmers since they should not need to know that async functions are implementated using generators.

This change generators a different name depending on the generator kind, allowing us to tell whether the generator is the result of an async block, an async closure, an async fn, or a plain generator.

r? `@tmandry`
cc `@michaelwoerister` `@wesleywiser` `@dpaoliello`

…r=dtolnay

Add Sync bound to allocator parameter in vec::IntoIter

The `A: Sync` bound was forgotten in rust-lang@8725e4c#diff-b78c3ab6d37f4ede32195707528f8a76c49d4557cc9d3a7a09417b5157729b9fR3132

Similar `unsafe impl Sync` in that commit _do_ include the `A: Sync` bound (and around the alloc lib), so I think this was just an honest mistake.

Here's an example of the unsoundness:  https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=16cbfeff7c934ae72ab632c1476fdd8b

`@steffahn` found this, I'm just putting up the fix cause nobody else did :^)

Fixes rust-lang#92633

…-const-block, r=fee1-dead

Do not fail evaluation in const blocks

Evaluate const blocks with a const param-env, so we properly check `~const` trait bounds.

Fixes rust-lang#92713
(I will fix the poor diagnostics in rust-lang#92713 and rust-lang#92712 in a separate PR)

cc `@nbdd0121` who wrote the code this PR touches in rust-lang#89561