chore(deps): bump windows-core from 0.62.2 to 0.100.0 in the windows group

[dependabot]

Bumps the windows group with 1 update: windows-core.

Updates windows-core from 0.62.2 to 0.100.0

Commits

• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

[github-actions]

Thanks @dependabot[bot] for taking the time to contribute.

This repository is observing a maintainer-managed PR intake gate in dry-run mode, so this pull request is staying open. This note helps maintainers prepare the allowlist before any enforcement is considered.

Please read CONTRIBUTING.md for the expected contribution shape. A maintainer can grant recurring PR access by commenting /lgtm on a pull request.

[Hmbown]

Brought this branch up to date with main (green since ccbef2c) so CI runs against a base that passes; the earlier red lanes were inherited from the red main this PR was opened on. Merging once the re-run is green.

---

Generated by Claude Code

[claude]

Claude finished @Hmbown's task in 1m 24s —— View job

---

Reviewing dependabot PR #6359 (windows-core 0.62.2 → 0.100.0)

• Gather context (PR diff, changed files)
• Understand the request (code review of the diff)
• Review the diff
• Post findings

---

Summary

This bump touches crates/tui/Cargo.toml and Cargo.lock. The catch: windows-core was bumped from 0.62 to 0.100, but the sibling windows = { version = "0.62", ... } dependency was not bumped alongside it (that's outside dependabot's "windows" group scope here). That breaks an invariant the code explicitly documents and relies on.

Correctness bug (blocking)

crates/tui/Cargo.toml:169 / crates/tui/src/tui/window_control.rs:59,360-376

The comment directly above the changed line says:

// `windows` re-exports most of windows-core's types but not all of them
// (BOOL, HRESULT, … live in windows-core itself); window_control.rs names
// windows_core::BOOL for the EnumWindows callback, so it must be a direct
// dependency. Version already resolved via `windows` — no extra build work.
windows-core = { version = "0.100" }

That "version already resolved via windows" claim is now false. Per Cargo.lock, windows 0.62.2 still pins windows-core 0.62.2 as its own dependency, while crates/tui now pulls windows-core 0.100.0 directly — two distinct major versions of windows-core in the tree (visible in the lock diff: "windows-core 0.62.2" for the windows/windows-future/wasm-bindgen deps vs "windows-core 0.100.0" for codewhale-tui).

In window_control.rs:360-376:

unsafe extern "system" fn enum_proc(hwnd: HWND, lparam: LPARAM) -> BOOL {
    ...
    return BOOL(0); // stop enumeration
    ...
    BOOL(1)
}
...
let _ = EnumWindows(Some(enum_proc), LPARAM(&mut ctx as *mut Ctx as isize));

HWND/LPARAM come from windows::Win32::Foundation (re-exported, backed by windows-core 0.62.2), but BOOL at line 59 is now imported from the direct windows_core dependency, which resolves to 0.100.0 — a different, incompatible type from Rust's point of view even though the name is identical. EnumWindows's callback parameter type is generated against windows's own windows-core 0.62.2-backed BOOL. Passing enum_proc (returning the 0.100.0 BOOL) where a 0.62.2 BOOL fn-pointer is expected is a type mismatch — this should fail to compile with cfg(windows) enabled, i.e. on every Windows build (CI does build on windows-latest, e.g. .github/workflows/ci.yml, release-artifacts.yml).

Fix: keep windows-core pinned to the same range windows resolves (0.62, not 0.100) so the two stay on one shared version, or bump windows to a version whose own windows-core dependency matches 0.100 (if the two APIs are still compatible after such a large jump). Either way the code comment's stated invariant needs to hold again, or be updated to explain the new arrangement.

Other notes

• The rest of the Cargo.lock diff (transitive windows-sys bumps 0.59/0.60 → 0.61.2, windows-link 0.2.1 duplication, etc.) is the expected fallout of the group bump and looks fine on its own — it's specifically the direct windows-core version divergence from windows that's the problem.
• No provider/model/route-safety-relevant code, no tests, no security-sensitive code in this diff — those review dimensions don't apply here.

[devin-ai-integration]

Devin Review found 1 potential issue.

[devin-ai-integration]

🔍 Dependency comment contradicts resolution

windows-core no longer shares windows' 0.62.2 resolution. The lockfile now carries separate 0.62.2 and 0.100.0 support stacks.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[codewhale-agent]

Codewhale review did not run

codewhale review --pr 6359 (provider: deepseek) could not reach the model: Review pass 1/1 request failed: Responses API request failed: LLM error: HTTP 402: Insufficient Balance; no partial review was accepted or posted; publication: n.
This is a provider funding/config problem, not a finding about this PR. The check stays advisory; a maintainer with secret access needs to fund or rotate the review key (see .github/workflows/codewhale-review.yml). Re-run the workflow after that.

[Hmbown]

Not mergeable as opened: the bump splits the windows crate family. After the branch update, Test (windows-latest) fails at compile (job):

error[E0308]: mismatched types
   --> crates\tui\src\tui\window_control.rs:380:38
    |     let _ = EnumWindows(Some(enum_proc), LPARAM(&mut ctx as *mut Ctx as isize));
    = note: expected fn pointer `unsafe extern "system" fn(HWND, LPARAM) -> windows_result::bool::BOOL`
                  found fn item `unsafe extern "system" fn(HWND, LPARAM) -> windows_core::BOOL {enum_proc}`

This PR moves only windows-core to 0.100 while windows stays at 0.62, which still depends on windows-core 0.62.2, so the lockfile now carries both versions. window_control.rs names windows_core::BOOL (now the 0.100 type) for a callback that windows 0.62 expects in its own 0.62 BOOL. The Cargo.toml comment on this dependency already says the version has to be the one windows resolves; a windows-core bump is only valid in lockstep with windows.

Leaving this open for a maintainer decision rather than merging red. The clean fix is to have window_control.rs name windows::core::BOOL and drop the direct windows-core dependency, so the two can never drift again; then a future windows bump carries windows-core with it.

---

Generated by Claude Code

[Hmbown]

Superseded by #6390, now merged.

Rather than bump windows-core 0.62.2 to 0.100.0, #6390 removes the direct dependency entirely. It was never needed: the manifest comment claimed the windows crate "re-exports most of windows-core's types but not all of them (BOOL, HRESULT, ... live in windows-core itself)", but crates/tui/src/plugins/registry.rs:2203 already does use windows::core::{BOOL, PCWSTR}; and compiles on the Windows CI lane today.

window_control.rs now names windows::core::BOOL like its neighbour, and Cargo.lock loses exactly one edge under codewhale-tui. The crate is still built transitively via windows, so nothing loses it - there is simply no direct dependency left for this bump to target.

Thanks, dependabot.

[dependabot]

This pull request was built based on a group rule. Closing it will not ignore any of these versions in future pull requests.

To ignore these dependencies, configure ignore rules in dependabot.yml