Skip to content

deps(fuzz): bump windows-sys from 0.60.2 to 0.61.2 in /fuzz - #3

Open
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/cargo/fuzz/windows-sys-0.61
Open

deps(fuzz): bump windows-sys from 0.60.2 to 0.61.2 in /fuzz#3
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/cargo/fuzz/windows-sys-0.61

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Aug 20, 2026 •
edited
Loading

Copy link
Copy Markdown

Bumps windows-sys from 0.60.2 to 0.61.2.

Release notes

Sourced from windows-sys's releases.

61

Major crate updates:

  • windows 0.59.0
  • windows-core 0.59.0
    • windows-implement 0.59.0
    • windows-interface 0.59.0
  • windows-targets 0.53.0
    • windows_i686_msvc 0.53.0
    • windows_x86_64_msvc 0.53.0
    • windows_aarch64_msvc 0.53.0
    • windows_i686_gnu 0.53.0
    • windows_x86_64_gnu 0.53.0
    • windows_i686_gnullvm 0.53.0
    • windows_x86_64_gnullvm 0.53.0
    • windows_aarch64_gnullvm 0.53.0
  • windows-bindgen 0.59.0
  • windows-registry 0.4.0
  • windows-result 0.3.0
  • windows-strings 0.3.0
  • cppwinrt 0.2.0

Minor crate updates:

  • windows-version 0.1.2

Excluded:

  • windows-sys 0.59.0

Things to keep in mind:

  • The tag/release names no longer map directly to the crate versions, so to find samples for a particular release requires looking at the releases page and finding the release that most recently updated a particular crate.

  • The windows-bindgen crate includes the major code generation overhaul that brings many improvements - be sure to check out the PR description for more information. The resulting code gen depends on the new version of windows-core and its dependencies, unless you include the --sys option. #3359

  • The cppwinrt crate constitutes a major update due to streamlining the error handling. #3415

  • The windows-registry, windows-strings, and windows-result crates are also major version updates since they include small breaking changes.

  • The windows-targets crate finally receives a major version update, the first in over a year. This is due to #3359 and #3342 potentially introducing breaking changes. Although unlikely, these updates introduced sufficient changes that make it hard to ensure that the windows-targets libs don't break existing code. As we're updating windows-targets anyway, I took the liberty to bump the MSRV to 1.60 - to match the latest version of windows-sys - and remove the old but unused doc macro feature. Both remained for compatibility with very old dependents of the windows-targets crate.

  • The windows-version crate receives a minor update to update its dependency on the windows-targets crate.

  • Beyond these specifics, this update is the culmination of around 6 months worth of work on the windows-rs project. The biggest improvements comes from the new code generation engine, but many other improvements are now also available for production. This includes support for many new lints, warnings, and suggestions provided by the Rust toolchain; much smaller code gen thanks to deriving many more traits; more efficient code gen; major improvements to WinRT type system and implementation support; more robust and consistent error handling; stock collection and async support; improved support for class hierarchies; and much more!

In addition to "what's changed" below, check out what's changed for notes for 0.60.0 and 0.59.0 for additional changes that roll up to the crates published as part of this release.

What's Changed

... (truncated)

Commits

@dependabot @github

dependabot Bot commented on behalf of github Aug 20, 2026

Copy link
Copy Markdown
Author

Labels

The following labels could not be found: dependencies, fuzz. Please create them before Dependabot can add them to a pull request.

Please fix the above issues or remove invalid values from dependabot.yml.

@dependabot
dependabot Bot force-pushed the dependabot/cargo/fuzz/windows-sys-0.61 branch from 722a979 to 05c8d83 Compare August 20, 2026 02:38
Ttimmahlax pushed a commit that referenced this pull request Aug 20, 2026
@tim-almond-house @claude
Hardening pass 4: a semgrep rule from our own history found the 0.4.0…
4f243a6 
… bug still live on the huge path

Core ★ 12/15, and 89% of gates overall (was 74%). Every remaining code-level
gate is closed; what is left needs a signature or a calendar.

THE FINDING. tools/semgrep-rules.yml encodes five rules taken from this
project's incident log rather than a generic ruleset. One looks for
`debug_assert!(false, ..)` used as an error path — the shape behind 0.4.0
defect #3, where a failed unlink vanished in release and the caller freed the
segment anyway. It fired on `Heap::remove_huge_segment`: the normal-segment
path was fixed in 0.4.0, the HUGE path was not.

    self.remove_huge_segment(seg);   // found nothing, silently, in release
    let _ = huge_free(seg);          // ...released it regardless

Fixed like its sibling: -> bool, #[must_use] naming the consequence, caller
releases only what it unlinked. Same lesson the 0.4.0 entry already records —
put the outcome in the type — applied to the site that was missed.

The other five gates, each an instrument run here for the first time:

- H-30 Kani: 5 harnesses, all VERIFICATION SUCCESSFUL. The important one
  proves page_of's slice index is in range for EVERY in-segment offset — the
  contract justifying M10b's removal of its bounds check. Miri/fuzzing/loom
  say "no counterexample found"; this says none exists. Limits stated:
  --ignore-global-asm (Kani cannot analyse the TLS global_asm!; no harness
  touches it) and the two bin proofs are bounded to 2*MEDIUM_OBJ_SIZE_MAX
  because unbounded 64-bit leading_zeros reasoning did not terminate.
- H-34 ChaCha8 vetted: the quarter-round — the whole cryptographic core — now
  checks against RFC 8439 §2.1.1's published vector; block layout against the
  RFC's state; counter advance AND carry (a stuck counter repeats the
  keystream). 7 tests.
- H-19 foreign-pointer guard: free() consults the segment map before deriving
  metadata, so a pointer we never returned is caught at the call instead of
  producing a wild slot.sub(off). Zero release cost (measured), and PROVEN to
  fire by tests/foreign_free.rs — a gate nobody has watched fail is not a gate.
- H-22 static analysis: the five rules above, plus semgrep-selftest.sh which
  asserts they still fire on synthesised bad code, so the job cannot go green
  by matching nothing. Two rules were refined after false positives (the
  correctly-cfg-gated counters; a doc comment describing the bad shape) — the
  rule was wrong, not the code.
- H-11 unsafe ratchet: cargo-geiger does not compile on 1.97.1 in any version
  tried, so the substitution is tools/unsafe-census.sh + a committed baseline
  that FAILS on growth. It caught its own weakness on first use — v1 counted
  the word "unsafe" in a doc comment and tripped on proofs.rs. A gate that
  cries wolf over prose gets re-baselined unread, so it now strips comments.
- H-38 is half done and stays Incomplete: SHA256SUMS + build-provenance
  attestation are wired into release.yml; tag signing needs the owner's key.

Supply chain: adding proptest grew the DEV tree (rand/zerocopy/ppv-lite86).
cargo vet regenerated — 31 fully audited, 28 exempted, and ZERO exemptions are
safe-to-deploy, which is the property that matters: nothing shipping is
uncertified.

Gates: Linux battery PASSED, Windows 31 suites, corpus sweep 19/19, churn 3/3,
deny/audit/vet clean, semgrep clean + selftest OK, ratchet OK, hot path
unchanged (batch 60.17, small 79.38).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Ttimmahlax pushed a commit that referenced this pull request Aug 20, 2026
@tim-almond-house @claude
Make the huge-path unlink fix REPRODUCED, not merely reasoned
1f6feba 
The fix itself landed in 4f243a6 (remove_huge_segment -> bool + #[must_use],
caller releases only what it unlinked). What it lacked was the thing this
ledger already complains about for the 0.3.2-era repairs: a test that fails
when the bug comes back. teardown_reclaim.rs "passes 4/4 with the bug
deliberately reintroduced" — a guard that guards nothing.

The obstacle was structural: with `debug_assert!` inline, a test build panics
on the not-found path, so the `false` return — the entire point of the fix —
can never be observed. So the walk is now split:

  try_unlink_huge_segment  the DECISION, no diagnostic (testable)
  remove_huge_segment      decision + debug_assert (unchanged behaviour)

heap::unlink_tests checks the decision directly, and was verified BOTH WAYS:
returning `true` instead of `false` on the not-found path makes it fail with
a message naming defect #3; restoring the fix makes it pass. That is the
difference between a regression test and a reassuring one.

Side effect worth noting: the split also removes the `debug_assert!(false, ..)`
shape entirely, so the semgrep rule no longer needs a nosemgrep suppression
there — the code stopped matching the bad pattern instead of being excused
from it.

The +3 unsafe occurrences from the split were documented in UNSAFE.md and
re-baselined, which is the H-11 ratchet doing its job on its author.

Gates: Linux battery PASSED, Windows 31 suites, semgrep clean, ratchet OK.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Ttimmahlax pushed a commit that referenced this pull request Aug 20, 2026
root @claude root
perf(opps #5): calloc/zalloc zero with the page in hand — calloc 152.…
34021e6 
…62 -> 132.00 (-20.62 Ir/op)

The public zalloc/calloc did malloc(size) then zero_block(p, is_zero), and
zero_block's non-zero arm (taken on every RECYCLED block, i.e. the steady calloc
churn path) called usable_size(p): mask to the segment, resolve the page, check
the segment kind, un-align — all to recover a block_size the allocator held one
field-load away.

New Heap::zalloc pops the block with the page still in hand and zeroes using
(*p).block_size directly. The re-resolution is gone from the hot recycled path;
the rare slow/large path still recovers it the general way.

Measured (callgrind opscan, freshly built): calloc 152.62 -> 132.00, 0.949x ->
0.820x vs mimalloc. Every other op is BYTE-IDENTICAL — small 79.38, batch_lifo
60.17, realloc 379.53, mixed 140.07 — because the plain malloc/free path is not
touched; only the zeroing entry point changed. The stronger-than-mimalloc
full-extent zeroing contract is preserved: zalloc still zeroes the whole usable
extent, and zalloc_is_zero_across_the_whole_usable_extent still passes.

Verified: workspace release green, all-features clippy clean, secure+blockmap
suite green (bar the documented WSL purge flake).

Also in this commit, opps.md #3 (bounds-check audit): 39 panic_bounds_check sites
lib-wide, but ZERO reachable from the shipped malloc / free / calloc fast paths
(confirmed by disassembling the override .so). All 39 are on slow/cold paths.
The safe-Rust hot path pays no bounds-check tax.

Co-Authored-By: Claude Fable 5 (1M context) <noreply@anthropic.com>
Ttimmahlax pushed a commit that referenced this pull request Aug 20, 2026
root @claude root
docs(opps #3, #4): record the two Tier-2 investigations that ship no …
7972f6e 
…code

#3 bounds-check audit — DONE, and the headline is that there is nothing to fix
on the hot path: 39 panic_bounds_check sites lib-wide, ZERO reachable from the
shipped malloc / free / calloc fast paths (confirmed on the override .so). All
39 are on slow/cold paths (segment alloc/free, visitors, arena, teardown, and 2
on the malloc_generic refill). The safe-Rust allocator pays no bounds-check tax
where it matters. The 2 refill checks resisted a min(MAX_NORMAL_BIN) clamp on
bin (count unchanged) and sit on a cold path — not worth chasing, recorded so
the dead end is not re-explored.

#4 update_direct recompute — ASSESSED, premise false. bin_size(bin) for the
common bin <= 8 is bin << 3 (a shift), and bin_size(bin-1) runs only for
bin > 8. There is no costly recompute on the hot path, and replacing the shift
with a table/stored load would reintroduce a panic_bounds_check (bin from
bins::bin is unbounded to LLVM) that costs more than it saves. Left as-is.

Both are honest negative results with the evidence attached, which is the point
of the register: they stop the next person re-attempting a dead end. The Tier-2
win that DID land is #5 (calloc -20.62 Ir/op), committed separately.

Co-Authored-By: Claude Fable 5 (1M context) <noreply@anthropic.com>
@dependabot
deps(fuzz): bump windows-sys from 0.60.2 to 0.61.2 in /fuzz
a56bd77 
Bumps [windows-sys](https://github.com/microsoft/windows-rs) from 0.60.2 to 0.61.2.
- [Release notes](https://github.com/microsoft/windows-rs/releases)
- [Commits](https://github.com/microsoft/windows-rs/commits)

---
updated-dependencies:
- dependency-name: windows-sys
  dependency-version: 0.61.2
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot changed the title deps(fuzz): update windows-sys requirement from 0.60 to 0.61 in /fuzz deps(fuzz): bump windows-sys from 0.60.2 to 0.61.2 in /fuzz Aug 20, 2026
@dependabot
dependabot Bot force-pushed the dependabot/cargo/fuzz/windows-sys-0.61 branch from 05c8d83 to a56bd77 Compare August 20, 2026 22:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants