style(lib): Address clippy panics and missing_panics_doc lints

[Siech0]

• The description, docs, and comments (words meant for humans) are written by a human, not by an LLM. (https://seanmonstar.com/micro/20260729-i-want-your-own-words/)

Towards #4071

Most of the panics are structurally unreachable, I attempted to reproduce them with adversarial workflows (panics, malformed inputs, etc) and I believe they are truly unreachable so I have marked them as unreachable!(...). This will still panic if it is hit, but it makes the intent clear and avoids needing a panic doc.

Two panics were reproducible and have had their panic docs written.

Connection::without_shutdown @ src/server/conn/http1.rs:184

// `without_shutdown` returns `impl Future`, so it can be driven by hand.
let mut conn = Box::pin(conn.without_shutdown());
let mut cx = Context::from_waker(Waker::noop());

assert!(conn.as_mut().poll(&mut cx).is_ready());

// Polling a completed future panics.
let _ = conn.as_mut().poll(&mut cx);

ReadBufCursor::advance @ src/rt/io.rs:346

let mut raw = [0u8; 8];
let mut rb = ReadBuf::new(&mut raw);
let mut cursor = rb.unfilled();
unsafe { cursor.advance(usize::MAX) }; // filled: 0 -> usize::MAX, no panic
unsafe { cursor.advance(1) };          // usize::MAX + 1 overflows and expect fires

Both cases are pretty silly to ever hit, but documentation is free.

[seanmonstar]

Thanks for taking this on! 2 notes inline.

[seanmonstar]

I think using expect in this case, polling a completed future, is normal. I wouldn't call this unreachable, because if the user does so, it sounds like we made a mistake.

But the docs of Future indicate the user should not do so. I don't think we need to document that behavior.

[Siech0]

Fixed. Thanks for the prompt review!

Please note, on rebase I hit more lints and have updated accordingly.

[seanmonstar]

Same here, this is basically expected from the Future docs, we can leave it off.

[Siech0]

Fixed.

[Siech0]

I've addressed all findings and I've also gone and updated the commit message and formatting to meet repo guidelines.

[0x676e67]

Alright, looks like we still need to fix the cargo fmt issue.

[Siech0]

Alright, looks like we still need to fix the cargo fmt issue.

This time it seems it was due to MSRV, I had't realized allow block reasons were recent. Sorry for the mistake. I've updated it now.