Files
bun.sh/test
robobun 3cb1b5c7dd Fix CSS parser crash with large floating-point values (#21907) (#21909)
## 🐛 Problem

Fixes #21907 - CSS parser was crashing with "integer part of floating
point value out of bounds" when processing extremely large
floating-point values like `3.40282e38px` (commonly generated by
TailwindCSS `.rounded-full` class).

### Root Cause Analysis

**This revealed a broader systemic issue**: The CSS parser was ported
from Rust, which has different float→integer conversion semantics than
Zig's `@intFromFloat`.

**Zig behavior**: `@intFromFloat` panics on out-of-range values
**Rust behavior**: `as` operator follows safe conversion rules:
- Finite values within range: truncate toward zero
- NaN: becomes 0  
- Positive infinity: becomes target max value
- Negative infinity: becomes target min value
- Out-of-range finite values: clamp to target range

The crash occurred throughout the CSS codebase wherever `@intFromFloat`
was used, not just in the original failing location.

## 🔧 Comprehensive Solution

### 1. New Generic `bun.intFromFloat` Function
Created a reusable function in `src/bun.zig` that implements
Rust-compatible conversion semantics:

```zig
pub fn intFromFloat(comptime Int: type, value: anytype) Int {
    // Handle NaN -> 0
    if (std.math.isNan(value)) return 0;
    
    // Handle infinities -> min/max bounds
    if (std.math.isPositiveInf(value)) return std.math.maxInt(Int);
    if (std.math.isNegativeInf(value)) return std.math.minInt(Int);
    
    // Handle out-of-range values -> clamp to bounds
    const min_float = @as(Float, @floatFromInt(std.math.minInt(Int)));
    const max_float = @as(Float, @floatFromInt(std.math.maxInt(Int)));
    if (value > max_float) return std.math.maxInt(Int);
    if (value < min_float) return std.math.minInt(Int);
    
    // Safe conversion for in-range values
    return @as(Int, @intFromFloat(value));
}
```

### 2. Systematic Replacement Across CSS Codebase
Replaced **all 18 instances** of `@intFromFloat` in `src/css/` with
`bun.intFromFloat`:

| File | Conversions | Purpose |
|------|-------------|---------|
| `css_parser.zig` | 2 × `i32` | CSS dimension serialization |
| `css_internals.zig` | 9 × `u32` | Browser target version parsing |
| `values/color.zig` | 4 × `u8` | Color component conversion |
| `values/color_js.zig` | 1 × `i64→u8` | Alpha channel processing |
| `values/percentage.zig` | 1 × `i32` | Percentage value handling |
| `properties/custom.zig` | 1 × `i32` | Color helper function |

### 3. Comprehensive Test Coverage
- **New test suite**: `test/internal/int_from_float.test.ts` with inline
snapshots
- **Enhanced regression test**: `test/regression/issue/21907.test.ts`
covering all conversion types
- **Real-world testing**: Validates actual CSS processing with edge
cases

## 📊 esbuild Compatibility Analysis

Compared output with esbuild to ensure compatibility:

**Test CSS:**
```css
.test { border-radius: 3.40282e38px; }
.colors { color: rgb(300, -50, 1000); }
.boundaries { width: 2147483648px; }
```

**Key Differences:**
1. **Scientific notation format:**
   - esbuild: `3.40282e38` (no explicit + sign)  
   - Bun: `3.40282e+38` (explicit + sign)
   -  Both are mathematically equivalent and valid CSS

2. **Optimization strategy:**
   - esbuild: Preserves original literal values
   - Bun: Normalizes extremely large values + consolidates selectors
   -  Bun's more aggressive optimization results in smaller output

###  Question for Review

**@zackradisic** - Is it acceptable for Bun to diverge from esbuild in
this optimization behavior?

- **Pro**: More aggressive optimization (smaller output, consistent
formatting)
- **Con**: Different output format than esbuild
- **Impact**: Both outputs are functionally identical in browsers

Should we:
1.  Keep current behavior (more aggressive optimization)
2. 🔄 Match esbuild exactly (preserve literal notation)
3. 🎛️ Add flag to control this behavior

##  Testing & Validation

- [x] **Original crash case**: Fixed - no more panics with large
floating-point values
- [x] **All conversion types**: Tested i32, u32, u8, i64 conversions
with edge cases
- [x] **Browser compatibility**: Verified targets parsing works with
extreme values
- [x] **Color processing**: Confirmed RGB/RGBA values properly clamped
to 0-255 range
- [x] **Performance**: No regression - conversions are equally fast
- [x] **Real-world**: TailwindCSS projects with `.rounded-full` work
without crashes
- [x] **Inline snapshots**: Capture exact expected output for future
regression detection

## 🎯 Impact

### Before (Broken)
```bash
$ bun build styles.css
============================================================
panic: integer part of floating point value out of bounds
```

### After (Working)
```bash
$ bun build styles.css  
Bundled 1 module in 93ms
  styles.css  121 bytes  (asset)
```

-  **Fixes crashes** when using TailwindCSS `.rounded-full` class on
Windows
-  **Maintains backward compatibility** for existing projects  
-  **Improves robustness** across all CSS float→int conversions
-  **Better optimization** with consistent value normalization

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

---------

Co-authored-by: Claude Bot <claude-bot@bun.sh>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
2025-08-15 20:59:50 -07:00
..
2025-07-29 18:07:15 -07:00
2025-08-14 22:42:05 -07:00
2025-08-04 23:30:46 -07:00
2025-08-14 22:42:05 -07:00

Tests

Finding tests

Tests are located in the test/ directory and are organized using the following structure:

  • test/
    • js/ - tests for JavaScript APIs.
    • cli/ - tests for commands, configs, and stdout.
    • bundler/ - tests for the transpiler/bundler.
    • regression/ - tests that reproduce a specific issue.
    • harness.ts - utility functions that can be imported from any test.

The tests in test/js/ directory are further categorized by the type of API.

  • test/js/
    • bun/ - tests for Bun-specific APIs.
    • node/ - tests for Node.js APIs.
    • web/ - tests for Web APIs, like fetch().
    • first_party/ - tests for npm packages that are built-in, like undici.
    • third_party/ - tests for npm packages that are not built-in, but are popular, like esbuild.

Running tests

To run a test, use Bun's built-in test command: bun test.

bun test # Run all tests
bun test js/bun # Only run tests in a directory
bun test sqlite.test.ts # Only run a specific test

If you encounter lots of errors, try running bun install, then trying again.

Writing tests

Tests are written in TypeScript (preferred) or JavaScript using Jest's describe(), test(), and expect() APIs.

import { describe, test, expect } from "bun:test";
import { gcTick } from "harness";

describe("TextEncoder", () => {
  test("can encode a string", async () => {
    const encoder = new TextEncoder();
    const actual = encoder.encode("bun");
    await gcTick();
    expect(actual).toBe(new Uint8Array([0x62, 0x75, 0x6E]));
  });
});

If you are fixing a bug that was reported from a GitHub issue, remember to add a test in the test/regression/ directory.

// test/regression/issue/02005.test.ts

import { it, expect } from "bun:test";

it("regex literal should work with non-latin1", () => {
  const text = "这是一段要替换的文字";
  expect(text.replace(new RegExp("要替换"), "")).toBe("这是一段的文字");
  expect(text.replace(/要替换/, "")).toBe("这是一段的文字");
});

In the future, a bot will automatically close or re-open issues when a regression is detected or resolved.

Zig tests

These tests live in various .zig files throughout Bun's codebase, leveraging Zig's builtin test keyword.

Currently, they're not run automatically nor is there a simple way to run all of them. We will make this better soon.

TypeScript

Test files should be written in TypeScript. The types in packages/bun-types should be updated to support all new APIs. Changes to the .d.ts files in packages/bun-types will be immediately reflected in test files; no build step is necessary.

Writing a test will often require using invalid syntax, e.g. when checking for errors when an invalid input is passed to a function. TypeScript provides a number of escape hatches here.

  • // @ts-expect-error - This should be your first choice. It tells TypeScript that the next line should fail typechecking.
  • // @ts-ignore - Ignore the next line entirely.
  • // @ts-nocheck - Put this at the top of the file to disable typechecking on the entire file. Useful for autogenerated test files, or when ignoring/disabling type checks an a per-line basis is too onerous.