chore(tui): name windows::core::BOOL and drop the direct windows-core dependency - #6390
Conversation
… dependency
crates/tui declared windows-core as a direct dependency for one import:
window_control.rs named `windows_core::BOOL` for the EnumWindows callback.
The manifest comment said `windows` does not re-export BOOL, but it does:
plugins/registry.rs in this same crate already imports
`windows::core::{BOOL, PCWSTR}` and compiles on the Windows lane.
The separate pin is what broke dependabot's #6359. It bumped windows-core to
0.100 while `windows` stayed at 0.62, so the callback's BOOL (windows-core
0.100) no longer matched the BOOL that `windows` 0.62's EnumWindows expects
(windows-core 0.62): E0308 on the Windows compile. Naming the type through
`windows` keeps a single windows-core in the graph, chosen by `windows`.
Validation: `cargo metadata --locked` exits 0 and the Cargo.lock delta is
the single removed `windows-core` edge under codewhale-tui. The changed code
is cfg(windows) and cannot be compiled on the macOS host, so the Windows CI
lane is the compile receipt for this change.
Supersedes #6359
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
|
Claude finished @Hmbown's task in 44s —— View job Claude finished reviewing this PR
|
![codewhale-agent[bot]](https://avatars.githubusercontent.com/u/101357273?s=60&v=4){kind=small}
There was a problem hiding this comment.
Codewhale review
Complete review coverage: 1/1 passes, 3 file patches, sha256:883c0dfae21bdaedcd1d8ef8294748c40e34af04bb97f26bdee11673cdb6faa5.
Pass 1: This pass removes the direct windows-core dependency from crates/tui/Cargo.toml, drops the now-unnecessary "windows-core", edge from the codewhale-tui entry in Cargo.lock, and switches crates/tui/src/tui/window_control.rs from use windows_core::BOOL; to use windows::core::BOOL;. The path change is type-identical: windows::core re-exports windows_core, so windows::core::BOOL resolves to the same type that EnumWindows's WNDENUMPROC expects, and the neighbouring Windows code already uses windows::core imports. The removed manifest stanza was a target-gated (cfg(target_os = "windows")) dependency; windows-core remains in the graph transitively through windows, so no consumer loses the crate. Source inspection found no defect introduced by these three edits.
Assessment
Pass 1: No defect identified in the diff. The change is a dependency-graph and path-alias cleanup: windows::core::BOOL and windows_core::BOOL are the same type reached through the windows crate's unconditional core re-export, so the EnumWindows callback signature in window_control.rs is unaffected, and the Cargo.lock edit removes exactly the direct edge that the manifest change makes stale while leaving the transitive windows-core package resolved. Two limits on this assessment are worth stating explicitly rather than treating as findings. First, this module is #[cfg(windows)], so none of it is compiled on a non-Windows host; whether the head actually builds the Windows lane is not established by this review (no build, test or cargo metadata --locked run was performed here). The relevant risk would be a remaining windows_core:: reference elsewhere in the crate that the removed dependency had been satisfying — the diff changes only the one site visible here, and the reviewers' own search claim cannot be independently confirmed from the supplied excerpts, since crates/tui/src/plugins/registry.rs and the rest of the crate were not included. If such a reference existed, the failure would be a Windows-only unresolved-crate compile error, which the Windows CI lane would surface. Second, the exact contents of the omitted manifest tail (lines 162-164 of the head) were not shown; the diff hunk header is consistent with the file ending at the windows = { version = "0.62", ... } line, and the removal leaves that entry intact. Neither point is evidence of a bug; both are verification gaps.
Advisory review by Codewhale (codewhale review --pr 6390 --post, head a5bc6b845d65fbf1ace5307bfd9005469dce629c). Line-specific findings are also posted as inline review comments; mechanical fixes arrive as committable suggestions you can apply from the Files tab. CODEOWNERS approval still governs merge.
Supersedes Dependabot's #6359 (
windows-core0.62.2 → 0.100.0) by removingthe direct dependency instead of bumping it.
Why the dependency was never needed
crates/tui/Cargo.tomlcarried a directwindows-core = { version = "0.62" }with a comment claiming the
windowscrate "re-exports most of windows-core'stypes but not all of them (BOOL, HRESULT, … live in windows-core itself)".
That comment is wrong, and the repository already disproves it:
crates/tui/src/plugins/registry.rs:2203doesuse windows::core::{BOOL, PCWSTR};and compiles on the Windows CI lane today.So
window_control.rsnow nameswindows::core::BOOLlike its neighbour, thedirect dependency and its incorrect comment come out of
Cargo.toml, andCargo.lockloses exactly one"windows-core",edge undercodewhale-tui.The crate is still built — transitively, via
windows— so this changes nobuild work and no behaviour. Dependabot's bump then has nothing to target.
Evidence
windows_core::references remain anywhere undercrates/.Cargo.lockdelta is one line;cargo metadata --lockedexits 0.Unverified locally, by construction: this code is
cfg(target_os = "windows")and cannot be compiled on macOS. The Windows CIlane on this PR is the compile receipt — it is the only proof that matters
here, and it has not run yet at the time of writing.
🤖 Generated with Claude Code
No-Issue: dependency cleanup. It supersedes Dependabot's PR #6359 by removing the dependency rather than bumping it; whether to close that PR is a separate maintainer decision, so no closing keyword is used here.