deno
31b81a59 - qjs_v8_compat + ext/node: critical string-bleed fix; polyfills now load

Commit
60 days ago
qjs_v8_compat + ext/node: critical string-bleed fix; polyfills now load Two real fixes that unblock substantial bootstrap progress: 1. **WriteUtf8Buf for String must clear before pushing** — deno_core's `runtime::ops::to_string` reuses a thread-local `String` buffer across every #[string] op argument, calling `write_utf8_into` once per call without resetting. Our `append_str` impl was using `push_str`, so the buffer accumulated. Result: the second op call that took a string saw a CONCATENATION of the first call's string plus its own. With deno_node's ~1k op_load_ext_script calls, every specifier after the first was wrong, and the very first `loadExtScript("inspect.mjs")` from errors.ts blew up with `cannot lazy-load "errors.tsinspect.mjs"`. Real V8's contract is overwrite-on-write; clear the buffer first so the existing reuse-friendly callers behave correctly. 2. **Script::run leaves the pending exception in place** — was draining it via `take_pending_exception` before returning None, breaking `tc_scope.has_caught()` for the caller. Real V8 leaves the exception so the enclosing TryCatch picks it up. Added a peek that re-throws the exception after logging stack — keeps diagnostics without breaking semantics. Plus: - `ext/node/build.rs` now walks `polyfills/` and `js/` and emits `cargo:rerun-if-changed` for every file. Without this, edits to any .ts/.js polyfill went undetected by cargo and weren't included in the next build. - `Object::get_prototype` actually calls `JS_GetPrototype` instead of returning a perpetual None (deno_core's `is_instance_of_error` walks the prototype chain). Net effect: bootstrap now compiles `inspect.mjs`, `validators.mjs`, `error_codes.ts` — at least 4 polyfill files past the previous failure point.
Author
Parents
Loading