Repository navigation
Mark windows-ioring-sys breaking for the CallbackEnviron it exposes - #161
Merged
Merged
Conversation
…e windows-threadpool-sys' CallbackEnviron, and mark the breaking change Both constructors take Option<&mut CallbackEnviron>, the type of the windows-threadpool-sys this crate depends on, so a new version of that crate is a different parameter type here. The windows-threadpool-sys release that moves to 0.4 would otherwise reach this crate as a patch bump: release-please's cargo-workspace plugin releases a dependent of a breaking crate as a patch, and nothing on the branch that merged the dependency carried the marker. This commit carries it, and documents on both constructors what the type is and which version a caller must build it with. Found by the Copilot review of the release pull request. Swept the other crates that depend on a crate this release breaks, for the same exposure: win-multi-file-tail-watcher, windows-file-watcher, windows-platform-probes and windows-thread-ambient-sys (a dev-dependency only) expose none of its types in a public signature, field or re-export. BREAKING CHANGE: EventDelivery::new and CompletionWake::new take the CallbackEnviron of the windows-threadpool-sys 0.4 this crate now depends on, which is not the CallbackEnviron of the 0.3 it depended on; a caller that builds one passes the one from the version this crate resolves to. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
Both documentation changes match the existing constructor contracts, with no unresolved blocking issues.
No open issues 🎉
What changed in this PR
Supports the breaking-release correction for windows-ioring-sys in #160 by documenting the dependency type exposed by its public constructors.
Changes:
- Clarifies that both constructors accept
CallbackEnvironfrom thewindows-threadpool-sysversion resolved by this crate. - Uses version-independent wording; no signatures or runtime behavior change.
| File | Description |
|---|---|
crates/windows-ioring-sys/src/event_delivery.rs |
Documents the environment type requirement for EventDelivery::new. |
crates/windows-ioring-sys/src/completion_wake.rs |
Adds the same clarification to CompletionWake::new. |
Review effort: Balanced
This file contains hidden or 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
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.
Summary
Marks
windows-ioring-sysas breaking for the release PR (#160), and documents why.EventDelivery::newandCompletionWake::neware public and takeOption<&mut CallbackEnviron>, the type of thewindows-threadpool-systhis crate depends on. The release PR moves that crate from 0.3 to 0.4 and proposeswindows-ioring-sys0.8.1. A client that builds aCallbackEnvironfrom its own 0.3 dependency would stop compiling against it. Copilot's review of #160 found this.release-please's
cargo-workspaceplugin releases a dependent of a breaking crate as a patch, and no commit on the branch that merged the dependency carried the marker for this crate. The commit here is afix(ioring)!:with aBREAKING CHANGE:footer, so the next release PR proposes 0.9.0 for it. It touches onlycrates/windows-ioring-sys.The code change is two doc paragraphs, on both constructors, saying what
envis and that a caller must build it with the version ofwindows-threadpool-systhis crate resolves to. They name no version, so they cannot go stale.Audit
Every crate in the release PR that is on a compatible bump and has a normal dependency on a crate the same release breaks, checked for that crate's types in a public signature, field or re-export:
windows-ioring-sys: exposesCallbackEnviron(the two constructors). Fixed here.win-multi-file-tail-watcher,windows-file-watcher,windows-platform-probes: none.windows-thread-ambient-sys: depends on it as a dev-dependency only, so it cannot expose it.The
windows-threadpool-sysandwin-sync-syschanges were already marked breaking.Verification
cargo fmt, clippy with all targets, and rustdoc with broken intra-doc links denied pass for the crate, andtools/check-commit-scope.ps1reports no multi-crate release commit.Not in this PR: #160 also has a failing test in
windows-platform-probes(build_identity::tests::this_crate_reads_its_own_stamps_not_the_placement_probes), which asserts that the two probe crates' versions differ, and both get2026.1022.0in that release. This PR does not change that.