Buffer.allocUnsafe and Buffer.byteLength fail at codegen Phase 2 (compile-fatal) #630

Repro

// repro_a.ts
import { Buffer } from "node:buffer";
const b = Buffer.allocUnsafe(8);
console.log(b.fill(0xab).toString("hex"));

// repro_b.ts
import { Buffer } from "node:buffer";
console.log(Buffer.byteLength("hello", "utf8"));

Actual (Perry)

Both files fail at compile, exit 1:

Error compiling module 'repro_a.ts' (...): lowering entry of module 'repro_a.ts':
  lowering init statements of module 'repro_a.ts':
    perry-codegen Phase 2: expression BufferAllocUnsafe not yet supported

Error compiling module 'repro_b.ts' (...): lowering entry of module 'repro_b.ts':
  lowering init statements of module 'repro_b.ts':
    perry-codegen Phase 2: expression BufferByteLength not yet supported

Expected (Node)

abababababababab

5

Impact

These two are foundational Buffer APIs — used by virtually every Node library that touches binary data. Buffer.byteLength(s, "utf8") is the canonical "how many bytes does this string take?" probe used by Content-Length headers, hash inputs, network framing, etc. Buffer.allocUnsafe is the recommended fast-path allocator (faster than Buffer.alloc because it skips zeroing).

Currently any file importing them fails at compile time — there's no PERRY_ALLOW_UNIMPLEMENTED workaround because the failure happens during HIR lowering, not at runtime dispatch.

Both have HIR variants (Expr::BufferAllocUnsafe, Expr::BufferByteLength) so the lowering recognizes them; codegen Phase 2 just doesn't have arms for them yet. Most adjacent buffer ops (Buffer.alloc, Buffer.from, Buffer.concat) work fine — these two are clear gaps.

Acceptance

Both repros above compile + run with Perry, byte-identical to Node.

Related

Surfaced while building test-files/test_parity_buffer.ts (parity gap report). Both lines are currently // PERRY-SKIP: codegen-fatal in the test file; uncomment when fixed.