Error compiling for Windows- expression UrlSearchParamsGet not yet supported

[amirlogic]

I tried to compile the file http.js (after converting to http.ts) in https://github.com/amirlogic/node-sea-apps

perry check: OK

Error compiling module 'http.ts' (\?\C:...\http.ts) with --backend llvm: lowering closure func_id=5: lowering closure body func_id=5: perry-codegen Phase 2: expression UrlSearchParamsGet not yet supported

[proggeramlug]

Fixed in 4afc71e (v0.5.117).

Root cause — three layers stacked:

1. params.get(...) had been lowering to Expr::UrlSearchParamsGet in the HIR for a while, but only the JS and WASM emitters had arms for it. The LLVM backend hit the catch-all in crates/perry-codegen/src/expr.rs and bailed with the error you saw. The other six UrlSearchParams* variants and every UrlGet* scalar getter had the same gap — they just hadn't been hit yet by a user program.
2. crates/perry-codegen/src/runtime_decls.rs declared js_url_get_* as I64 -> I64, but the Rust runtime returns f64, so even once the handlers were wired the values would have flowed through the wrong register class on the C ABI.
3. crates/perry-runtime/src/url.rs::create_url_object had a // TODO: URLSearchParams that stored the raw search string in the URL's searchParams slot. So const p = url.searchParams; p.get(...) via generic PropertyGet would hand the URLSearchParams runtime a StringHeader disguised as an ObjectHeader — segfault when reading _entries. Now stores a real URLSearchParams object NaN-boxed with POINTER_TAG, so both lowering paths (typed-URL → UrlGetSearchParams codegen, and untyped property read) converge on the same object.

Verified byte-for-byte against Node for a 12-line repro covering new URL() + .pathname + .searchParams.{get,has,set,append,getAll,delete,toString}. If you perry upgrade (or pull main) and recompile http.ts, it should build clean now. Thanks for the report!