-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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 7 pull requests #104138
Rollup of 7 pull requests #104138
Conversation
The table rows were obtained via the script embedded in the page.
These lines (including the FIXME comment) were added to windows_gnu_base.rs in cf2c492 but windows_gnullvm_base.rs was not updated. This resulted in an error `LLVM ERROR: dwo only supported with ELF and Wasm` attempting to build on aarch64-pc-windows-gnullvm. Signed-off-by: Jeremy Drake <[email protected]>
The helper shell script has been rewritten as a helper Python script that generates the range-based table.
This also updates the existing iter::Copied::next_chunk benchmark so that the thing it benches doesn't get masked by the ArrayChunks specialization
This is fairly safe use of TRA since it consumes the iterator so no struct in an unsafe state will be left exposed to user code
The type is unsafe and now exposed to the whole crate. Document it properly and add an unsafe method so the caller can make it visible that something unsafe is happening.
…imulacrum Specialize `iter::ArrayChunks::fold` for TrustedRandomAccess iterators ``` OLD: test iter::bench_trusted_random_access_chunks ... bench: 368 ns/iter (+/- 4) NEW: test iter::bench_trusted_random_access_chunks ... bench: 30 ns/iter (+/- 0) ``` The resulting assembly is similar to rust-lang#103166 but the specialization kicks in under different (partially overlapping) conditions compared to that PR. They're complementary. In principle a TRA-based specialization could be applied to all `ArrayChunks` methods, including `next()` as we do for `Zip` but that would have all the same hazards as the Zip specialization. Only doing it for `fold` is far less hazardous. The downside is that it only helps with internal, exhaustive iteration. I.e. `for _ in` or `try_fold` will not benefit. Note that the regular, `try_fold`-based and the specialized `fold()` impl have observably slightly different behavior. Namely the specialized variant does not fetch the remainder elements from the underlying iterator. We do have a few other places in the standard library where beyond-the-end-of-iteration side-effects are being elided under some circumstances but not others. Inspired by https://old.reddit.com/r/rust/comments/yaft60/zerocost_iterator_abstractionsnot_so_zerocost/
…apes, r=wesleywiser Fix `rustc_parse_format` spans following escaped utf-8 multibyte chars Currently too many skips are created for char escapes that are larger than 1 byte when encoded in UTF-8, [playground:](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=c77a9dc669b69b167271b59ed2c8d88c) ```rust fn main() { format!("\u{df}{a}"); format!("\u{211d}{a}"); format!("\u{1f4a3}{a}"); } ``` ``` error[[E0425]](https://doc.rust-lang.org/stable/error-index.html#E0425): cannot find value `a` in this scope --> src/main.rs:2:22 | 2 | format!("\u{df}{a}"); | ^ not found in this scope error[[E0425]](https://doc.rust-lang.org/stable/error-index.html#E0425): cannot find value `a` in this scope --> src/main.rs:3:25 | 3 | format!("\u{211d}{a}"); | ^ not found in this scope error[[E0425]](https://doc.rust-lang.org/stable/error-index.html#E0425): cannot find value `a` in this scope --> src/main.rs:4:27 | 4 | format!("\u{1f4a3}{a}"); | ^ not found in this scope ``` This reduces the number of skips to account for that Fixes rust-lang/rust-clippy#9727
…red-tracking, r=eholk Move `fallback_has_occurred` state tracking to `FnCtxt` Removes a ton of callsites that defaulted to `false`
Update linker-plugin-lto.md to contain up to Rust 1.65 The table rows were obtained via the script embedded in the page.
…=eholk Remove `in_tail_expr` from FnCtxt Cleans up yet another unneeded member from `FnCtxt`. The `in_tail_expr` condition wasn't even correct -- it was set for true while typechecking the whole fn body.
fix debuginfo for windows_gnullvm_base.rs These lines (including the FIXME comment) were added to windows_gnu_base.rs in cf2c492 but windows_gnullvm_base.rs was not updated. This resulted in an error `LLVM ERROR: dwo only supported with ELF and Wasm` attempting to build on aarch64-pc-windows-gnullvm. See also msys2/MINGW-packages#13921 (comment) /cc ```@mati865``` ```@davidtwco``` r? ```@davidtwco```
…eywiser fully move `on_unimplemented` to `error_reporting` the `traits` module has a few too many submodules in my opinion.
@bors r+ rollup=never p=5 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR: previous master: 6b23a7e87f In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (57d3c58): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. |
Successful merges:
iter::ArrayChunks::fold
for TrustedRandomAccess iterators #103446 (Specializeiter::ArrayChunks::fold
for TrustedRandomAccess iterators)rustc_parse_format
spans following escaped utf-8 multibyte chars #103651 (Fixrustc_parse_format
spans following escaped utf-8 multibyte chars)fallback_has_occurred
state tracking toFnCtxt
#103865 (Movefallback_has_occurred
state tracking toFnCtxt
)in_tail_expr
from FnCtxt #103987 (Removein_tail_expr
from FnCtxt)on_unimplemented
toerror_reporting
#104094 (fully moveon_unimplemented
toerror_reporting
)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup