-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 8 pull requests #92927
Rollup of 8 pull requests #92927
Conversation
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
@bors r+ rollup=never p=8 |
📌 Commit 539175c has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (b13a5bf): comparison url. Summary: This benchmark run did not return any relevant changes. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
Successful merges:
&mut
fromio::read_to_string
signature #92863 (Remove&mut
fromio::read_to_string
signature)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup