lib: refactor internal webidl converters#62979
Conversation
|
Review requested:
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #62979 +/- ##
==========================================
+ Coverage 89.67% 89.70% +0.02%
==========================================
Files 707 707
Lines 219509 219952 +443
Branches 42093 42102 +9
==========================================
+ Hits 196851 197300 +449
+ Misses 14551 14550 -1
+ Partials 8107 8102 -5
🚀 New features to boost your workflow:
|
|
i'm nearing the end of what i can optimize on the hot paths, just one more fixup then i'll do a final benchmark |
This comment was marked as outdated.
This comment was marked as outdated.
|
Benchmark CI: https://ci.nodejs.org/view/Node.js%20benchmark/job/benchmark-node-micro-benchmarks/1842 |
Rework lib/internal/webidl.js into a documented shared converter module that follows the Web IDL conversion algorithms more closely. Improvements: - Add documented converters and helper factories for primitive values, dictionaries, enums, sequences, interfaces, required arguments, integers, `Uint8Array`, and `BufferSource`. - Move WebCrypto onto the shared converters, while keeping compatibility wrappers for its existing `BufferSource` and `BigInteger` behavior. - Use shared converters from Blob, Performance, Web Locks, and structured clone option handling. - Add benchmarks for `ConvertToInt` and WebCrypto Web IDL converter hot paths. - Add focused tests for core converters, WebCrypto converters, integer conversion, and buffer source behavior. Fixes: - Make the shared `BufferSource` and `Uint8Array` converters reject resizable `ArrayBuffer` and growable `SharedArrayBuffer` backing stores unless explicitly allowed. WebCrypto preserves its legacy resizable backing-store behavior through compatibility wrappers until a semver-major follow-up can opt in to the stricter behavior. - Use Web IDL `ToNumber` and `ToString` behavior for BigInt, Symbol, and object primitive conversion. - Use exact BigInt modulo for 64-bit `ConvertToInt` wrapping and document the final Number approximation behavior. - Normalize mathematical modulo results to `+0` where Web IDL requires it. - Process inherited dictionaries in least-derived to most-derived order, sorting members only within each dictionary level. - Use `IteratorComplete` truthiness for sequence conversion. - Cover detached buffers, resizable-backed views, growable-backed views, cross-realm buffer sources, mutation-after-call behavior, inherited dictionary member order, and sequence iterator completion behavior. Signed-off-by: Filip Skokan <[email protected]>
|
(just a rebase, no changes) |
|
@KhafraDev should we make an effort to build something that can be reused by node.js core and undici? |
I plan on starting exactly that. |
|
I'm not sure, I'm not too interested in adding a dependency to undici and both have different requirements. In undici we don't care about primordials, node does. Node implements different specs than undici, so each platform would still have to implement their own converters (the core is easy to implement relatively speaking). |
|
@KhafraDev I'm not sure what Matteo had in mind but i had Nevertheless, that's probably for another issue's discussion. At this point here i'm looking for reviewers to make node's webidls better and faster. |
This comment was marked as outdated.
This comment was marked as outdated.
Renegade334
left a comment
There was a problem hiding this comment.
Thanks for taking this on!
| if (integer === V) { | ||
| return V === 0 ? 0 : V; | ||
| } | ||
| if (options === kEmptyObject || options.enforceRange || !options.clamp) { |
There was a problem hiding this comment.
Isn't the enforceRange check redundant here, since Clamp and EnforceRange are mutually exclusive? Could this just be if (options !== kEmptyObject && options.clamp) return evenRound(V)?
| * @returns {Converter} | ||
| */ | ||
| function createEnumConverter(name, values) { | ||
| const E = new SafeSet(values); |
There was a problem hiding this comment.
FWIW, note that this pattern (providing an array to a SafeMap/SafeSet constructor) is not prototype-safe.
| // Do not use a primordial getter here. When this module is included in the | ||
| // startup snapshot, an early-captured SharedArrayBuffer.prototype.growable | ||
| // getter does not detect growable buffers created after deserialization. | ||
| // Lazily capturing the getter would work, but it would observe the runtime | ||
| // prototype at first comparison, so it would not be an actual primordial. |
There was a problem hiding this comment.
The alternative would be a binding for SharedArrayBuffer::GetBackingStore()->IsResizableByUserJavaScript() if we were really keen.
| return 'BigInt'; | ||
| case 'object': | ||
| case 'function': | ||
| default: |
There was a problem hiding this comment.
Would an unreachable assert.fail() be more appropriate for the default?
| // Web IDL IntegerPart steps 1-3: floor(abs(n)), restore the sign, | ||
| // and choose +0 rather than -0. | ||
| const integer = MathTrunc(n); | ||
| return integer === 0 ? 0 : integer; |
There was a problem hiding this comment.
Out of interest, would
return integer + 0;be any less performant? Would simplify quite a few patterns.
Rework lib/internal/webidl.js into a documented shared converter module that follows the Web IDL conversion algorithms more closely.
Improvements:
Uint8Array, andBufferSource.BufferSourceandBigIntegerbehavior.ConvertToIntand WebCrypto Web IDL converter hot paths.Fixes:
BufferSourceandUint8Arrayconverters reject resizableArrayBufferand growableSharedArrayBufferbacking stores unless explicitly allowed. WebCrypto preserves its legacy resizable backing-store behavior through compatibility wrappers until a semver-major follow-up can opt in to the stricter behavior.ToNumberandToStringbehavior for BigInt, Symbol, and object primitive conversion.ConvertToIntwrapping and document the final Number approximation behavior.+0where Web IDL requires it.IteratorCompletetruthiness for sequence conversion.Benchmark(s)
lib: refactor internal webidl converters #62979 (comment)