ReviewOS

home-lang/home

Make lol-html linkage self-contained and remove unsafe generic stubs

#199
Open chris opened this 10 days ago ·
10 days ago

Home currently links the real lol-html C API only when the gitignored .native/liblolhtml.a exists. scripts/build-lolhtml.sh builds that archive from a separate Bun checkout. Without it, native_stubs.zig exports generic no-op symbols whose undefined return registers can reach Zig unreachable branches.

The JavaScript corpus pass adds deterministic guards for HTMLRewriter construction and HTMLScanner execution when lol-html is absent, preventing the observed runtime panic.

Remaining work:

  • make the lol-html dependency reproducible from this repository/build graph
  • link it on supported targets in CI and release builds
  • replace/remove signature-unsafe generic fallbacks
  • validate native HTMLRewriter handler lifetime and Workerd regressions in release/ASAN lanes

Related corpus work: #198 Parent tracking: #66

10 days ago

Published the defensive half of this issue in 4fdaabf80.

When build_options.have_lolhtml is false:

  • HTMLRewriter construction now throws a deterministic JS error explaining that lol-html support is unavailable.
  • bundler HTMLProcessor.run now returns error.LolHtmlUnavailable before touching the generic no-op symbols.

This removes the previous path into an undefined lol-html register followed by unreachable; the no-archive debug build compiles and the native Workerd probe reports the explicit capability error instead of crashing.

The issue remains open for the structural fix: build/link lol-html self-contained inside Home so normal builds provide the feature rather than relying on a manually produced .native/liblolhtml.a.

10 days ago

Validated the real lol-html integration locally while removing the stale Bun.write corpus import rewrite in 078363fa4.

Using the repository's scripts/build-lolhtml.sh against the pinned Bun checkout produced the isolated 6.3 MiB C-API archive with all 96 lol_html_* text symbols. Debug and ReleaseSafe then exercised the native implementation across Bun.write plus three focused HTMLRewriter regressions:

  • pinned Bun: 43 pass, 0 fail, 1,443 assertions
  • Home Debug/ReleaseSafe strict: 43 pass, 0 fail, 1,443 assertions
  • Home Debug/ReleaseSafe routed: 43 pass, 0 fail
  • all four corpus files byte-identical to current Bun

Before linking the archive, the same Bun.write fixture failed only at HTMLRewriter.transform(Bun.file(...)) with the explicit unavailable-capability error. With the real archive linked it passes normally, including selector validation, handler validation, concurrent use, rejection-at-end, DOCTYPE mutation, and Bun.write streaming.

This issue remains open: .native/liblolhtml.a is still gitignored and manually produced, so the dependency is not yet self-contained in the normal build graph/CI.

Sign in to comment on this issue.