Uh oh!
There was an error while loading. Please reload this page.
Document unsafe blocks in core::{cell, str, sync} - #66564
Conversation
rust-highfive
commented
Nov 20, 2019
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @RalfJung (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
RalfJung
commented
Nov 20, 2019
Cc @rust-lang/wg-unsafe-code-guidelines |
RalfJung
commented
Nov 20, 2019
There are also still some open comments at #66506 |
JohnCSimon
commented
Nov 24, 2019
Ping from triage |
JohnCSimon
commented
Nov 30, 2019
Pinging again from triage: |
foeb
commented
Nov 30, 2019
@JohnCSimon I've addressed the comments as much as I can without further comments from the reviewer. |
JohnCSimon
commented
Dec 14, 2019
Ping from triage: |
RalfJung
commented
Dec 14, 2019
My status is that I still don't know when I will have the time to look at this -- sorry. With the holidays coming up, my free time has diminished to basically zero. |
There was a problem hiding this comment.
Besides data races, a major concern here is invalidating pointers. The reason this is safe is that Cell rules out interior pointers -- there can be nothing pointing into either of these Cell, so we can swap out their content just fine.
This applies to the other unsafe blocks in this file as well.
There was a problem hiding this comment.
Also, "not threadsafe is okay" is negative reasoning, that's somewhat backwards. What we need here is positive evidence that there cannot be a race, and that evidence is that Cell is !Sync. I think that's what you mean by your second use of the word "threadsafe" but it's not entirely clear.
There was a problem hiding this comment.
So sorry for the long delay. I expected this to be huge amounts of work so I pushed it back again and again to start the review... turns out I hardly know most of this code so I can't intelligently review it anyway. :/
This mostly looks good to me, modulo the comments I left. However I had to skip most of the str module as I am entirely unfamiliar with that code. Could someone from @rust-lang/libs check that part?
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Casting to a raw const ptr is always possible so I a somewhat puzzled by this comment. Also, why does this implication hold? Not sure how you are going from align-index to `ptr.add(index)´.
And it's not really align-index anyway, it's wrapping_sub, but add must not overflow. So why does this all fit together?^^ (Probably this should be reviewed by someone who has seen this code before...)
There was a problem hiding this comment.
Yeah, this is one part where I'm still unsure that it's correct, even after reading through the code a dozen times. I'd appreciate hearing why this works from someone who's familiar with the code, too.
There was a problem hiding this comment.
This took me a while to understand, but basically:
alignis an offset in the string at which pointptr.add(align)is guaranteed to be usize-aligned.- If
align - indexis a multiple ofusize_bytesthenptr.add(index)is usize-aligned.
Uh oh!
There was an error while loading. Please reload this page.
bors
commented
Dec 23, 2019
☔ The latest upstream changes (presumably #67540) made this pull request unmergeable. Please resolve the merge conflicts. |
5e02e58 to
9f4f19aCompareRalfJung
commented
Dec 30, 2019
Picking a @rust-lang/libs reviewer (not sure if team pings are checked by anyone)... r? @Amanieu. See #66564 (review) for my own review results. |
Amanieu
commented
Dec 31, 2019
This looks good to me (minus that one comment), but needs to be rebased. |
Dylan-DPC-zz
commented
Jan 16, 2020
@foeb can you rebase this? thanks |
Co-Authored-By: Ralf Jung <post@ralfj.de>
9f4f19a to
c103c28Comparerust-highfive
commented
Jan 17, 2020
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
foeb
commented
Jan 17, 2020
@Dylan-DPC Thanks for the ping! I've rebased the branch and it should be ready to be merged. |
Dylan-DPC-zz
commented
Jan 17, 2020
@bors r=Amanieu |
bors
commented
Jan 17, 2020
📌 Commit 022a7de has been approved by |
bors
commented
Jan 17, 2020
⌛ Testing commit 022a7de with merge 2ea51420ade2ad385c4950a1faa919da73f0a812... |
Dylan-DPC-zz
commented
Jan 17, 2020
@bors retry (doing this to yield to a rollup retry ) |
…l-str, r=Amanieu
Document unsafe blocks in core::{cell, str, sync}
Split from rust-lang#66506 (issue rust-lang#66219). Hopefully doing a chunk at a time is more manageable!
r? @RalfJung…l-str, r=Amanieu
Document unsafe blocks in core::{cell, str, sync}
Split from rust-lang#66506 (issue rust-lang#66219). Hopefully doing a chunk at a time is more manageable!
r? @RalfJungRollup of 4 pull requests Successful merges: - #66564 (Document unsafe blocks in core::{cell, str, sync}) - #67791 (Implement Lift using interners instead of in_arena) - #68278 ([self-profiler] Add example to `-Z help` to turn on query key recording) - #68300 (Allow added string.insert benchmarks to compile) Failed merges: r? @ghost
bors
commented
Jan 17, 2020
| } | ||
| pub fn from_bytes(bytes: &[u8]) -> &Utf8Lossy { | ||
| // SAFETY: Both use the same memory layout, and UTF-8 correctness isn't required. |
There was a problem hiding this comment.
FWIW, they actually are not guaranteed to use the same memory layout -- Utf8Lossy has no repr annotations, so layout is unspecified. In this case I think adding repr(transparent) to Utf8Lossy is enough.
If you know of more such cases, it would be great if you could add them in rust-lang/unsafe-code-guidelines#90. :)
Correct safety reasoning in `str::make_ascii_{lower,upper}case()`
I don't understand why the previous comment was used (it was inserted in rust-lang#66564), but it doesn't explain why these functions are safe, only why `str::as_bytes{_mut}()` are safe.
If someone thinks they make perfect sense, I'm fine with closing this PR.
Split from #66506 (issue #66219). Hopefully doing a chunk at a time is more manageable!
r? @RalfJung