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 6 pull requests #97632

Merged
merged 20 commits into from
Jun 2, 2022
Merged

Rollup of 6 pull requests #97632

merged 20 commits into from
Jun 2, 2022

Conversation

JohnTitor
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

saethlin and others added 20 commits April 2, 2022 19:48
Split out from rust-lang#94247

This adds the following methods to raw slices that already exist on regular slices

* `*mut [T]::is_empty`
* `*mut [T]::split_at_mut`
* `*mut [T]::split_at_unchecked`

These methods reduce the amount of unsafe code needed to migrate ChunksMut and related iterators
to raw slices (rust-lang#94247)

Co-authored-by:: The 8472 <git@infinite-source.de>
`&mut [T]` implies validity which automatically makes `ptr::add` ok within its bounds.
But `*mut [T]` does not. Since we still want the benefits of in-bounds pointer arithmetic
`split_at_must` must require the caller to pass valid pointers and therefore it is `unsafe`.
Co-authored-by: Guillaume Gomez <guillaume1.gomez@gmail.com>
Additional `*mut [T]` methods

Split out from rust-lang#94247

This adds the following methods to raw slices that already exist on regular slices

* `*mut [T]::is_empty`
* `*mut [T]::split_at_mut`
* `*mut [T]::split_at_mut_unchecked`

These methods reduce the amount of unsafe code needed to migrate `ChunksMut` and related iterators
to raw slices (rust-lang#94247)

r? `@m-ou-se`
…estebank

Move conditions out of recover/report functions.

`Parser` has six recover/report functions that are passed a boolean, and
nothing is done if the boolean has a particular value.

This PR moves the tests outside the functions. This has the following effects.
- The number of lines of code goes down.
- Some `use` items become shorter.
- Avoids the strangeness whereby 11 out of 12 calls to
  `maybe_recover_from_bad_qpath` pass `true` as the second argument.
- Makes it clear at the call site that only one of
  `maybe_recover_from_bad_type_plus` and `maybe_report_ambiguous_plus` will be
  run.

r? `@estebank`
…-obk

Mention filename in suggestion when it differs from primary span
…e, r=GuillaumeGomez

rustdoc: Improve calculation of "Impls on Foreign Types"

The existing code to calculate whether an implementation was on a "Foreign Type" was duplicated across the sidebar generation and the page generation. It also came to the wrong conclusion for some cases where both the trait and the "for" type were re-exports.

This PR extracts the logic into a method of `Impl`, breaks it into a multi-line method so it can be commented, and adds a case for when the trait and the "for" type came from the same crate. This fixes some cases - like the platform-specific integer types (`__m256`, `__m128`, etc). But it doesn't fix all cases. See the screenshots below.

[Before](https://doc.rust-lang.org/nightly/std/clone/trait.Clone.html#foreign-impls):

<img src="https://user-images.githubusercontent.com/220205/171338226-59ce6daf-3d76-4bad-bc8d-72a8259a8f43.png" width=200>

[After](https://rustdoc.crud.net/jsha/implementation-is-on-local-type/std/clone/trait.Clone.html):

<img src="https://user-images.githubusercontent.com/220205/171338147-28308a65-1597-4223-be47-9550062404dd.png" width=200>

The remaining types (`CString`, `NulError`, etc) are all from the `alloc` crate, while the `Clone` trait is from the `core` crate. Since `CString` and `Clone` are both re-exported by `std`, they are logically local to each other, but I couldn't figure out a good way to detect that in this code. I figure this is still a good step forward.

Related: rust-lang#97610

r? `@camelid`
rename PointerAddress → PointerExposeAddress

`PointerAddress` sounds a bit too much like `ptr.addr()`, but this corresponds to `ptr.expose_addr()`.

r? `@tmiasko`
@rustbot rustbot added 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. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Jun 1, 2022
@JohnTitor
Copy link
Member Author

@bors r+ rollup=never p=6

@bors
Copy link
Contributor

bors commented Jun 1, 2022

📌 Commit b78c118 has been approved by JohnTitor

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Jun 1, 2022
@bors
Copy link
Contributor

bors commented Jun 1, 2022

⌛ Testing commit b78c118 with merge e838059...

@bors
Copy link
Contributor

bors commented Jun 2, 2022

☀️ Test successful - checks-actions
Approved by: JohnTitor
Pushing e838059 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 2, 2022
@bors bors merged commit e838059 into rust-lang:master Jun 2, 2022
@rustbot rustbot added this to the 1.63.0 milestone Jun 2, 2022
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (e838059): comparison url.

Instruction count

  • Primary benchmarks: no relevant changes found
  • Secondary benchmarks: 😿 relevant regression found
mean1 max count2
Regressions 😿
(primary)
N/A N/A 0
Regressions 😿
(secondary)
0.2% 0.2% 1
Improvements 🎉
(primary)
N/A N/A 0
Improvements 🎉
(secondary)
N/A N/A 0
All 😿🎉 (primary) N/A N/A 0

Max RSS (memory usage)

Results
  • Primary benchmarks: no relevant changes found
  • Secondary benchmarks: mixed results
mean1 max count2
Regressions 😿
(primary)
N/A N/A 0
Regressions 😿
(secondary)
3.4% 5.3% 3
Improvements 🎉
(primary)
N/A N/A 0
Improvements 🎉
(secondary)
-4.1% -4.1% 1
All 😿🎉 (primary) N/A N/A 0

Cycles

Results
  • Primary benchmarks: mixed results
  • Secondary benchmarks: 😿 relevant regression found
mean1 max count2
Regressions 😿
(primary)
2.2% 2.2% 1
Regressions 😿
(secondary)
1.8% 1.8% 1
Improvements 🎉
(primary)
-2.4% -2.5% 2
Improvements 🎉
(secondary)
N/A N/A 0
All 😿🎉 (primary) -0.9% -2.5% 3

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

Footnotes

  1. the arithmetic mean of the percent change 2 3

  2. number of relevant changes 2 3

@JohnTitor JohnTitor deleted the rollup-d2ucrjw branch June 2, 2022 03:39
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. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.