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

Document BinaryHeap unsafe functions #81706

Merged
merged 2 commits into from
Feb 21, 2021

Conversation

SkiFire13
Copy link
Contributor

BinaryHeap contains some private safe functions but that are actually unsafe to call. This PR marks them unsafe and documents all the unsafe function calls inside them.

While doing this I might also have found a bug: some "SAFETY" comments in sift_down_range and sift_down_to_bottom are valid only if you assume that child doesn't overflow. However it may overflow if end > isize::MAX which can be true for ZSTs (but I think only for them). I guess the easiest fix would be to skip any sifting if mem::size_of::<T> == 0.

Probably conflicts with #81127 but solving the eventual merge conflict should be pretty easy.

@rust-highfive
Copy link
Collaborator

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Feb 3, 2021
Copy link
Member

@Mark-Simulacrum Mark-Simulacrum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, this looks excellent. I think you are possibly right on the note about zero sized types; I think a PR adding the ZST bailout makes sense, but would need to do some more review on that. It would be good to add a FIXME comment into both methods that are likely affected to note down the problem.

library/alloc/src/collections/binary_heap.rs Outdated Show resolved Hide resolved
@Mark-Simulacrum Mark-Simulacrum added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 12, 2021
@SkiFire13
Copy link
Contributor Author

Oops, I guess I had to use rustbot. Anyway, let me try

@rustbot label -S-waiting-on-author +S-waiting-on-review

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Feb 16, 2021
@Mark-Simulacrum
Copy link
Member

Squashed out the rebase fix commit (feel free to do so in the future).

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Feb 20, 2021

📌 Commit 3ec1a28 has been approved by Mark-Simulacrum

@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 Feb 20, 2021
JohnTitor added a commit to JohnTitor/rust that referenced this pull request Feb 21, 2021
…e, r=Mark-Simulacrum

Document BinaryHeap unsafe functions

`BinaryHeap` contains some private safe functions but that are actually unsafe to call. This PR marks them `unsafe` and documents all the `unsafe` function calls inside them.

While doing this I might also have found a bug: some "SAFETY" comments in `sift_down_range` and `sift_down_to_bottom` are valid only if you assume that `child` doesn't overflow. However it may overflow if `end > isize::MAX` which can be true for ZSTs (but I think only for them). I guess the easiest fix would be to skip any sifting if `mem::size_of::<T> == 0`.

Probably conflicts with rust-lang#81127 but solving the eventual merge conflict should be pretty easy.
JohnTitor added a commit to JohnTitor/rust that referenced this pull request Feb 21, 2021
…e, r=Mark-Simulacrum

Document BinaryHeap unsafe functions

`BinaryHeap` contains some private safe functions but that are actually unsafe to call. This PR marks them `unsafe` and documents all the `unsafe` function calls inside them.

While doing this I might also have found a bug: some "SAFETY" comments in `sift_down_range` and `sift_down_to_bottom` are valid only if you assume that `child` doesn't overflow. However it may overflow if `end > isize::MAX` which can be true for ZSTs (but I think only for them). I guess the easiest fix would be to skip any sifting if `mem::size_of::<T> == 0`.

Probably conflicts with rust-lang#81127 but solving the eventual merge conflict should be pretty easy.
bors added a commit to rust-lang-ci/rust that referenced this pull request Feb 21, 2021
Rollup of 11 pull requests

Successful merges:

 - rust-lang#81300 (BTree: share panicky test code & test panic during clear, clone)
 - rust-lang#81706 (Document BinaryHeap unsafe functions)
 - rust-lang#81833 (parallelize x.py test tidy)
 - rust-lang#81966 (Add new `rustc` target for Arm64 machines that can target the iphonesimulator)
 - rust-lang#82154 (Update RELEASES.md 1.50 to include methods stabilized in rust-lang#79342)
 - rust-lang#82177 (Do not delete bootstrap.exe on Windows during clean)
 - rust-lang#82181 (Add check for ES5 in CI)
 - rust-lang#82229 (Add [A-diagnostics] bug report template)
 - rust-lang#82233 (try-back-block-type test: Use TryFromSliceError for From test)
 - rust-lang#82302 (Remove unsafe impl Send for CompletedTest & TestResult)
 - rust-lang#82349 (test: Print test name only once on timeout)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 56ae3fb into rust-lang:master Feb 21, 2021
@rustbot rustbot added this to the 1.52.0 milestone Feb 21, 2021
@SkiFire13 SkiFire13 deleted the document-binaryheap-unsafe branch February 21, 2021 16:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants