Age | Commit message (Collapse) | Author | Files | Lines |
|
<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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Follow up to https://github.com/tokio-rs/bytes/pull/689
* If `at == self.len()`, we already know `at <= self.len()`.
* If `at == 0`, we already know `at <= self.len()`.
|
|
* 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>
|
|
|
|
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`.
|
|
Signed-off-by: tison <wander4096@gmail.com>
|
|
If `at == self.len()` then we already know `at <= self.len()`. If
`at == 0`, it can't be greater than `self.len()`.
|
|
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`.
|
|
|
|
|
|
|
|
Bytes doesn't have an unsplit method anymore. We can always retrieve
these from git history if necessary.
|
|
|
|
Fixes #454.
|
|
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
|
|
* set len a little more concisely
* inline set_end
* remove kind assertions
* remove a duplicate assertion
* remove redundant assertion and min
* rename set_start to advance_unchecked
|
|
I can't see any reason that get_vec_pos needs a &mut self.
|
|
The second argument to `set_vec_pos` always contains the value of
`self.data`. Let's just use `self.data` and remove the second parameter
altogether.
|
|
We don't need the original capacity if the shared data is unique, so
let's not calculate it until after that check.
|
|
We're always subtracting here, and we already have a usize, so `sub`
seems like a more appropriate usage to me.
|
|
These seem to have been commented by accident in #298, and are still
passing.
|
|
Instead of re-declaring `vec`, we can just use a mut parameter.
|
|
|
|
|
|
|
|
|
|
Back in #362, an assertion was added to ensure that the alignment of
bytes::Shared is even so we can use the least significant bit as a flag.
bytes_mut::Shared uses the same technique but has no such assertion so
I've added one here.
|
|
|
|
|
|
|
|
I was a little confused about these calls using `Self::` instead of
`self.` here. Is there a reason to use the former instead of the latter?
|
|
This reworks `UninitSlice::as_uninit_slice_mut()` using equivalent
simpler logic.
|
|
Fixed a few broken links and converted a lot of them from the
html-link to intra-doc links.
|
|
Co-authored-by: Daniel Bauman <danielbauman@Daniels-MacBook-Pro.local>
|
|
|
|
|
|
|
|
|
|
|
|
tokio::io::ReadBuf uses names `new` and `uninit` for its constructors.
For consistency with that, rename recently introduced UninitSlice
constructors to match those names.
|
|
|
|
|
|
Introduce UninitSlice::from_slice and UninitSlice::from_uninit_slice
methods which safely create Uninit slice from provided slice of maybe
uninitialised or initialised memory.
In addition, add `From<&mut [T]>` implementations (for `T=u8` and
`T=MaybeUninit<u8>`) which do conversion from slice to UninitSlice.
Closes: #552
|