🐛 Make float/double/typed-array NaN generation non-canonical

[vishnujayvel]

Description

Fixes #6532

fc.float(), fc.double(), fc.float32Array() and fc.float64Array() always hardcoded Number.NaN as their "extra" NaN value. Since all NaN values are indistinguishable from each other at the JS language level (Number.isNaN, ===, Object.is...), these arbitraries could never surface the non-canonical NaN bit patterns (signaling NaNs, alternate payloads, negative NaNs...) that only become observable once a value is copied into a Float32Array/Float64Array — exactly the scenario @cschanhniem described in the issue.

Root cause and fix approach per @cschanhniem's analysis on the issue: reuse the single index that anyFloat/anyDouble already dedicate to NaN, but map it to a fixed non-canonical bit pattern instead of Number.NaN, rather than drawing extra randomness for a NaN "variant" index. The latter was tried first and reliably destabilized float32Array/float64Array's "shrink without initial context" contract (ArrayArbitrary drops per-element context, and IntegerArbitrary's context-free shrink target depends on the exact index range), so it was discarded in favor of this zero-extra-entropy design.

Two already-quiet, non-canonical 32/64-bit patterns are used (one for ranges extending past +0, one for ranges below it), avoiding signaling patterns since some engines quiet them when written into a TypedArray.

Impact: patch — no public API changes, only the underlying bit pattern of an already-produced NaN sentinel value changes (which is unobservable except via raw byte inspection, as described above).

Checklist

• I have a full understanding of every line in this PR — whether the code was hand-written, AI-generated, copied from external sources or produced by any other tool
• I flagged the impact of my change (minor / patch / major) either by running pnpm run bump or by following the instructions from the changeset bot
• I kept this PR focused on a single concern and did not bundle unrelated changes
• I followed the gitmoji specification for the name of the PR, including the package scope (e.g. 🐛(vitest) Something...) when the change targets a package other than fast-check
• I added relevant tests and they would have failed without my PR (when applicable)

Test plan

Ran locally on a fresh fork/clone against current main:

pnpm install
pnpm exec vitest run --project fast-check \
  packages/fast-check/test/unit/arbitrary/float.spec.ts \
  packages/fast-check/test/unit/arbitrary/double.spec.ts \
  packages/fast-check/test/unit/arbitrary/float32Array.spec.ts \
  packages/fast-check/test/unit/arbitrary/float64Array.spec.ts \
  packages/fast-check/test/unit/arbitrary/_internals/helpers/FloatHelpers.spec.ts \
  packages/fast-check/test/unit/arbitrary/_internals/helpers/FloatOnlyHelpers.spec.ts \
  packages/fast-check/test/unit/arbitrary/_internals/helpers/DoubleOnlyHelpers.spec.ts \
  packages/fast-check/test/unit/arbitrary/_internals/helpers/DoubleHelpers.spec.ts \
  packages/fast-check/test/e2e/arbitraries/FloatArbitrary.spec.ts \
  packages/fast-check/test/e2e/arbitraries/DoubleArbitrary.spec.ts \
  packages/fast-check/test/e2e/NoRegression.spec.ts
# → Test Files 11 passed (11), Tests 229 passed (229)

cd packages/fast-check && pnpm run typecheck   # → passes, no errors
pnpm run lint:check                            # → passes (pre-existing warnings only, none touch changed files)
pnpm run format:check                          # → passes, no diffs

I also confirmed the 4 new regression tests actually catch the bug: reverting only src/arbitrary/double.ts, src/arbitrary/float.ts, and their _internals/helpers/{Double,Float}Helpers.ts back to the pre-fix Number.NaN hardcoding (while keeping the new tests) makes exactly those 4 tests fail, confirming they would have failed without this PR:

• float32Array.spec.ts > should be able to produce non-canonical NaN bit patterns (see #6532)
• float64Array.spec.ts > should be able to produce non-canonical NaN bit patterns (see #6532)
• float.spec.ts > should properly convert the extra value to NaN
• double.spec.ts > should properly convert the extra value to NaN

The NoRegression e2e snapshot suite passes unchanged, confirming the index topology (and thus shrink behavior) is unaffected — only the sentinel's underlying bit pattern changed.

---

AI-assistance disclosure

In keeping with this project's contributing guidance: this contribution was prepared with AI assistance and was reviewed, run, and approved by me before submission — I understand the change and take responsibility for it.

What it does, in my words: the float/double/typed-array generators only ever emitted the canonical NaN bit pattern, so property tests could never exercise non-canonical NaNs (#6532). This maps the existing single NaN sentinel index to a fixed non-canonical bit pattern with zero additional entropy, so the value-index topology — and therefore all shrinking behaviour and the NoRegression snapshots — stays identical; only the sentinel's underlying bits change.

What I verified myself: the full test-plan above (229/229 targeted + NoRegression, typecheck/lint/format clean), plus the revert-confirms-fail check on the 4 new tests. Root-cause credit to @cschanhniem.

Happy to adjust anything to fit your preferences.

[changeset-bot]

🦋 Changeset detected

Latest commit: 52480c9

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
fast-check	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[dubzzz]

Actually so far we don't want to address that issue. Thanks for the suggestion but we might close it until we make it something we really want

[pkg-pr-new]

• @fast-check/examples

@fast-check/ava

npm i https://pkg.pr.new/@fast-check/ava@7136

fast-check

npm i https://pkg.pr.new/fast-check@7136

@fast-check/jest

npm i https://pkg.pr.new/@fast-check/jest@7136

@fast-check/packaged

npm i https://pkg.pr.new/@fast-check/packaged@7136

@fast-check/poisoning

npm i https://pkg.pr.new/@fast-check/poisoning@7136

@fast-check/vitest

npm i https://pkg.pr.new/@fast-check/vitest@7136

@fast-check/worker

npm i https://pkg.pr.new/@fast-check/worker@7136

commit: 52480c9

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.90%. Comparing base (5267837) to head (52480c9).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7136      +/-   ##
==========================================
+ Coverage   94.89%   94.90%   +0.01%     
==========================================
  Files         212      212              
  Lines        5951     5966      +15     
  Branches     1565     1566       +1     
==========================================
+ Hits         5647     5662      +15     
  Misses        296      296              
  Partials        8        8              

Flag	Coverage Δ
tests	94.90% <100.00%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[vishnujayvel]

Thanks for taking a look, and totally understand — no worries if it's not something you want to take on right now. Happy to close it, or leave it open as a reference for later, whatever's easiest for you. Appreciate the time either way. 🙏

[dubzzz]

I'm gonna look to it right before opening the 5.x version. It might be a good fit for 5.x as it may break some users with the new behaviour. That said the new behaviour is the one most of people should expect so a minor would be fine too.

[vishnujayvel]

Thanks for following up on it. Please keep me posted if you want me to rebase and publish it for new release in the future!

[vishnujayvel]

Circling back on this one — happy to rebase whenever you start planning the 5.x cut, since you mentioned this might fit better there given the behavior change. Let me know when that's on the horizon and I'll get it current.