Skip to content
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

Merged
merged 19 commits into from
Nov 8, 2022
Merged

Rollup of 7 pull requests #104138

merged 19 commits into from
Nov 8, 2022

Conversation

Dylan-DPC
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

Alexendoo and others added 19 commits October 27, 2022 18:20
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 <github@jdrake.com>
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.
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Nov 8, 2022
@Dylan-DPC
Copy link
Member Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Nov 8, 2022

📌 Commit c23068c has been approved by Dylan-DPC

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 8, 2022
@bors
Copy link
Contributor

bors commented Nov 8, 2022

⌛ Testing commit c23068c with merge 57d3c58...

@bors
Copy link
Contributor

bors commented Nov 8, 2022

☀️ Test successful - checks-actions
Approved by: Dylan-DPC
Pushing 57d3c58 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Nov 8, 2022
@bors bors merged commit 57d3c58 into rust-lang:master Nov 8, 2022
@rustbot rustbot added this to the 1.67.0 milestone Nov 8, 2022
@rust-timer
Copy link
Collaborator

📌 Perf builds for each rolled up PR:

PR# Perf Build Sha
#104094 a70884225c8df579d0cc2e91a113d6f1eb7d797f
#104067 00b5d53182e38ad2322d7a7e32815e04a01c0ba1
#103987 1723147f711d5022f5ddd1e480cbd0c89c7fc06a
#103955 59fbbba6192c5412100d211b319091a7a4a7be1e
#103865 d82c37ec289cbbbb8727ef82893d445ea579ae00
#103651 467b25f375599610c1370d899778413ad7e93efb
#103446 bffa39e05c7eb58d741c01cbbae56f11dd432454

previous master: 6b23a7e87f

In the case of a perf regression, run the following command for each PR you suspect might be the cause: @rust-timer build $SHA

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (57d3c58): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

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

mean range count
Regressions ❌
(primary)
3.7% [3.7%, 3.7%] 1
Regressions ❌
(secondary)
2.9% [2.9%, 2.9%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-5.3% [-6.9%, -3.7%] 2
All ❌✅ (primary) 3.7% [3.7%, 3.7%] 1

Cycles

This benchmark run did not return any relevant results for this metric.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants