feat: Implement ThreadAware for more more types#569
Conversation
There was a problem hiding this comment.
Pull request overview
This PR expands thread_aware’s coverage of “inert / relocation-no-op” types by adding a feature-gated ThreadAware implementation for tokio::sync::mpsc::UnboundedSender<T> and by adding a no-op impl for std::net::SocketAddr, along with tests and documentation updates.
Changes:
- Add
ThreadAwareno-op relocation support forstd::net::SocketAddr(with unit test). - Introduce a new
tokiofeature that enables aThreadAwareimpl fortokio::sync::mpsc::UnboundedSender<T>(plus tests). - Update crate docs/README and metadata (
allowed_external_types, dependency wiring) to reflect the newtokiofeature.
Reviewed changes
Copilot reviewed 6 out of 7 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| crates/thread_aware/src/third_party/tokio.rs | Adds the feature-gated ThreadAware impl for tokio::sync::mpsc::UnboundedSender<T> and validates behavior via tests. |
| crates/thread_aware/src/third_party/mod.rs | Registers the new tokio third-party module behind cfg(any(test, feature = "tokio")) and updates module docs. |
| crates/thread_aware/src/lib.rs | Documents the new tokio opt-in feature in the crate-level feature list. |
| crates/thread_aware/src/impls.rs | Adds a no-op ThreadAware impl for SocketAddr and a unit test verifying relocation is a no-op. |
| crates/thread_aware/README.md | Updates the generated README feature list to include tokio. |
| crates/thread_aware/Cargo.toml | Adds the tokio feature, dependency/dev-dependency entries, and allowlists the external Tokio type for external-types checking. |
| Cargo.lock | Records the new tokio dependency for thread_aware. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #569 +/- ##
========================================
Coverage 100.0% 100.0%
========================================
Files 356 360 +4
Lines 27388 27886 +498
========================================
+ Hits 27388 27886 +498 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
sandersaares
left a comment
There was a problem hiding this comment.
We need to define clear acceptance criteria in docs/DESIGN.md for why/when it is OK to add such out-of-box ThreadAware implementations. Today this feels like we are just randomly adding stuff here and I do not really see a rationale or a way to review whether something is OK to include or not in this way today. Certainly, including one random piece of Tokio feels weird (why not other pieces?).
@ralfbiedert can you help create these acceptance criteria so we can review this PR and other similar future PRs with some grounding?
I'm adding it because Ralf asked to add it so I assume it's ok to add it here. I don't have a comment on the acceptance criteria but that's not really in the scope of this PR. |
Sorry there was a misunderstanding. Adding |
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 6503296c-52d4-4236-82bb-958903e3e519
|
Removed the impl for the channel now |
sandersaares
left a comment
There was a problem hiding this comment.
I'm adding it because Ralf asked to add it so I assume it's ok to add it here. I don't have a comment on the acceptance criteria but that's not really in the scope of this PR.
This, combined with Ralf's reply, highlights the importance of including acceptance criteria. Let's please add at least a statement into AGENTS.md or DESIGN.md or similar that we can only add implementations for std without special exception here. If you think this is an egregious violation of this PR's scope, I am OK if you just file a work item to add this line later.
| assert_eq!(err_string, Err("error".to_string())); | ||
| } | ||
|
|
||
| #[test] |
There was a problem hiding this comment.
These tests are mostly useless and just noise. The only thing that should be asserted for most types is that the upstream type in fact impls it, which in and by itself can be a simple const fn assert_impl_threadware<T>() {}, which in turn violates M-TAUTOLOGICAL-TESTS.
There was a problem hiding this comment.
Makes sense, removed
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 6503296c-52d4-4236-82bb-958903e3e519
Implement ThreadAware for std::net::SocketAddr