Summary
V8 exposes the following public APIs for retrieving the identity assigned to a compiled classic script:
rusty_v8 currently does not expose either method.
Motivation
A Rust embedder may keep metadata for every classic script it compiles, such as its source record, source-map information, diagnostic labels, or the version of a dynamically loaded resource.
When an exception is reported later, V8 stack frames identify their scripts using V8-assigned script IDs. rusty_v8 already exposes this through StackFrame::get_script_id().
To associate those stack frames with the corresponding compilation records, the embedder also needs to obtain the V8-assigned ID from the Script or UnboundScript returned by the compilation API.
Resource names are not sufficient identifiers because the same resource may be compiled multiple times, and different scripts may use identical or missing resource names.
V8 exposes this identity through:
v8::Script::ScriptId()
v8::UnboundScript::ScriptId()
However, rusty_v8 currently does not expose either method. It already exposes the equivalent identity through Function::script_id(), Module::script_id(), and StackFrame::get_script_id().
Exposing the classic-script methods would allow embedders to correlate compilation records with exception and stack-trace diagnostics using V8's own script identity.
The existing ScriptOrigin::script_id() returns the value supplied when constructing the origin. It does not query the V8-assigned ID later reported by stack frames.
Proposed API
impl Script {
/// Returns the ID assigned to the underlying script by V8.
pub fn script_id(&self) -> i32;
}
impl UnboundScript {
/// Returns the ID assigned to this context-unbound script by V8.
pub fn script_id(&self) -> i32;
}
These would be thin bindings over the existing public V8 methods and follow the naming and return type already used by Function::script_id().
Tests
A binding test could compile a classic script and verify that the bound and unbound handles report the same ID:
let script = Script::compile(scope, source, Some(&origin)).unwrap();
let script_id = script.script_id();
let unbound_script = script.get_unbound_script(scope);
assert!(script_id > 0);
assert_eq!(unbound_script.script_id(), script_id);
If this API shape is acceptable, I would be happy to prepare a PR.
Summary
V8 exposes the following public APIs for retrieving the identity assigned to a compiled classic script:
v8::Script::ScriptId()v8::UnboundScript::ScriptId()rusty_v8currently does not expose either method.Motivation
A Rust embedder may keep metadata for every classic script it compiles, such as its source record, source-map information, diagnostic labels, or the version of a dynamically loaded resource.
When an exception is reported later, V8 stack frames identify their scripts using V8-assigned script IDs.
rusty_v8already exposes this throughStackFrame::get_script_id().To associate those stack frames with the corresponding compilation records, the embedder also needs to obtain the V8-assigned ID from the
ScriptorUnboundScriptreturned by the compilation API.Resource names are not sufficient identifiers because the same resource may be compiled multiple times, and different scripts may use identical or missing resource names.
V8 exposes this identity through:
v8::Script::ScriptId()v8::UnboundScript::ScriptId()However,
rusty_v8currently does not expose either method. It already exposes the equivalent identity throughFunction::script_id(),Module::script_id(), andStackFrame::get_script_id().Exposing the classic-script methods would allow embedders to correlate compilation records with exception and stack-trace diagnostics using V8's own script identity.
The existing
ScriptOrigin::script_id()returns the value supplied when constructing the origin. It does not query the V8-assigned ID later reported by stack frames.Proposed API
These would be thin bindings over the existing public V8 methods and follow the naming and return type already used by
Function::script_id().Tests
A binding test could compile a classic script and verify that the bound and unbound handles report the same ID:
If this API shape is acceptable, I would be happy to prepare a PR.