hyperium / hyperium/http-body

`Unpin` bound in `impl<P> Body for Pin<P>` is unnecessarily restrictive

Open
#167 0 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
173
Forks
69
Avg merge
6d 15h
Merged PRs (30d)
4

Description

the current code is :

impl<P> Body for Pin<P>
where
    P: Unpin + ops::DerefMut,
    P::Target: Body,
{
// ....
    fn poll_frame(
        self: Pin<&mut Self>,
        cx: &mut Context<'_>,
    ) -> Poll<Option<Result<Frame<Self::Data>, Self::Error>>> {
        Pin::get_mut(self).as_mut().poll_frame(cx)
    }
// ....
}

th correct code should be

impl<P> Body for Pin<P>
where
    P: ops::DerefMut,
    P::Target: Body,
{
// ....
    fn poll_frame(
        self: Pin<&mut Self>,
        cx: &mut Context<'_>,
    ) -> Poll<Option<Result<Frame<Self::Data>, Self::Error>>> {
        self.as_deref_mut().poll_frame(cx)
    }
// ....
}

without the Unpin bound. this likely has gone unnoticed as a !Unpin pinning pointer is a very strange idea, and all pinning pointers in std are Unpin.

but it is possible for such a type to exist, and thus this bound is making the api unnecessarily restrictive.

edit : i just saw as_deref_mut requires rust 1.84, which would be a significant bumb(prob unaceptably so) .
while there is no doubt this is sound in in earlier versions, i'm unsure wether the addition of unsafe code would be warranted.

maybe something to keep in mind for later , when/if http-body's msrv increases

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at the impl<P> Body for Pin<P> implementation shown in the issue and review how its Unpin bound affects !Unpin pointer types. Check the proposed as_deref_mut approach against the project's Rust MSRV and determine whether the bound can be removed without introducing unsupported or unjustified unsafe code.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
backend-api-design
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.