Cfg target has atomic v1.6.0 #4
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* writes low bytes, discards high bytes * panics if `nbytes` is greater than 8
Equivalent to
```
for _ in 0..cnt {
self.put_u8(val);
}
```
but may work faster.
Name and signature is chosen to be consistent with `ptr::write_bytes`.
Include three specializations:
* `Vec<u8>`
* `&mut [u8]`
* `BytesMut`
`BytesMut` and `&mut [u8]` specializations use `ptr::write`, `Vec<u8>`
specialization uses `Vec::resize`.
Co-authored-by: Taiki Endo <te316e89@gmail.com>
Rewrote the ledger in test_bytes_vec_alloc.rs to not piss off miri. The ledger is now a table within the allocator, which seems to satisfy miri. The old solution was to bundle an extra usize into the beginning of each allocation and then index past the start when deallocating data to get the size.
* Optimize `BytesMut::reserve`: Reuse vec if possible If the `BytesMut` holds a unqiue reference to `KIND_ARC` while the capacity of the `Vec` is not big enough , reuse the existing `Vec` instead of allocating a new one. Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>
I find this diagram very helpful, but a little hard to distinguish between the boxes and the lines that connect them. This commit redraws the boxes with line drawing characters so that the boxes appear a little more solid, and stand out from the other lines.
Previously, this code produced a &mut[u8] and a Box<[u8]> to the shared allocation upon cloning it. If the underlying allocation were actually shared, such as through a &[u8] from the Deref impl, creating either of these types incorrectly asserted uniqueness of the allocation. This fixes the example in #522, but Miri still does not pass on this test suite with -Zmiri-tag-raw-pointers because Miri does not currently understand int to pointer casts.
This reverts commit 89061c3. Why am I even able to push to master?
This adds an unsafe method to convert a `&mut UninitSlice` into a `&mut [MaybeUninit<u8>]`. This method is unsafe because some of the bytes in the slice may be initialized, and the caller should not overwrite them with uninitialized bytes. This came about when auditing [tokio-util's udp frame], where they want to pass the unitialized portion of a `BytesMut` to [ReadBuf::uninit]. They need to do this unsafe pointer casting in a few places, which complicates audits. This method lets us document the safety invariants the caller needs to maintain when doing this conversion. [tokio-util's udp frame]: https://github.com/tokio-rs/tokio/blob/master/tokio-util/src/udp/frame.rs#L87 [ReadBuf::uninit]: https://docs.rs/tokio/latest/tokio/io/struct.ReadBuf.html#method.uninit
Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>
Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com> Co-authored-by: Alice Ryhl <aliceryhl@google.com>
CI is [failing][failure] due to unused_imports because Iterator is already in the prelude. Removing it fixes things up. [failure]: https://github.com/tokio-rs/bytes/actions/runs/8034858583/job/21946873895
Bytes doesn't have an unsplit method anymore. We can always retrieve these from git history if necessary.
A fundamental invariant of `reserve` is that it can extend capacity while the stored data remains the same, even if it's moved to a new allocation. As a result, `len` can never change during a call to `reserve`.
If `at == self.len()` then we already know `at <= self.len()`. If `at == 0`, it can't be greater than `self.len()`.
Signed-off-by: tison <wander4096@gmail.com>
…s (#691) Closes #690 Without it, it seems to me that compiler is able to inline the vtable, resulting in similar results for `clone_shared` and `clone_arg_vec`.
* use checked_sub * return when additional == 0 * move safe operation out of unsafe block * use spare_capacity_mut instead of chunk_mut We don't need to check capacity because it's already been reserved above. * Add safety comments * refactor to use guard clauses This would be better written with let-else, but we won't get that until `MSRV >= 1.65.x`. * use if-let instead of unwrap * reduce scope of unsafe blocks Co-authored-by: Alice Ryhl <aliceryhl@google.com> --------- Co-authored-by: Alice Ryhl <aliceryhl@google.com>
Follow up to tokio-rs/bytes#689 * If `at == self.len()`, we already know `at <= self.len()`. * If `at == 0`, we already know `at <= self.len()`.
… (#710) <Arc<T>>::make_mut returns a &mut T, such an API is doable for Bytes too and thus we should reserve Bytes::make_mut for that. Furthermore, it would be helpful to use From<Bytes> as a trait bound in some cases with other traits such as Hyper's body trait, where Hyper gives you Bytes values. Finally, making it impl From<Bytes> for BytesMut means the API is more easily discoverable as it appears on both Bytes and BytesMut.
|
The best way forward would be for the upstream PR to be completed in the end. So, please try to create a new upstream PR based on tokio-rs/bytes#467. See the two comments: |
marius-meissner
force-pushed
the
cfg_target_has_atomic_v1.6.0
branch
from
fc0c35f
to
3074751
Compare
… on crate/patch level
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.