-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Codegen improvements #549
Codegen improvements #549
Conversation
This turns the generated code for a path expression into an actual generator function, which greatly simplifies keeping state between calls to next(). This also prevents calling getChildNodes for each step for each call to next(). Instead, the generated code now iterates over children using getFirstChild / getNextSibling.
This restores the ability to codegen @id = 'value', which was lost with the earlier annotation fix.
Turns out this was required to make the Closure compiler happy
Support for this is incomplete, only a few argument / return types are supported and built-in functions use an allowlist as we don't have the complete execution context available.
BundleMonFiles updated (2)
Total files change +2.55KB +1.55% Final result: ✅ View report in BundleMon website ➡️ |
That one doesn't need a generator, only a ternary expression
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome work! Especially like the yield statements! Makes the code way easier to read.
Left a few small nitpicky comments
mapPartialCompilationResult(nodesExpr, (nodesExpr) => | ||
acceptAst( | ||
`const ${stepContextItemExpr.code} of ${nodesExpr.code}`, | ||
{ type: GeneratedCodeBaseType.Statement }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Statement? Rather an iteratorHeader
or something. But fine for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, or rename Statement to NonExpressionCodeFragment or something... It's only used here so felt like overkill to introduce a separate type...
) => PartialCompilationResult | ||
> = { | ||
'local-name': emitLocalNameFunction, | ||
name: emitNameFunction, | ||
'local-name/0': emitLocalNameFunction, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nitpick, but I'd replace the /
with #
: to align with the functionLookup operator
src/jsCodegen/runtimeLib.ts
Outdated
args: UntypedExternalValue[], | ||
options: Options | null | ||
) => unknown; | ||
XPDY0002: typeof XPDY0002; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where is this used?
acceptAst(contextItemExpr.code, { type: GeneratedCodeBaseType.Value }, [ | ||
...contextItemExpr.variables, | ||
`if (${contextItemExpr.code} === undefined || ${contextItemExpr.code} === null) { | ||
throw new Error('XPDY0002: The function which was called depends on dynamic context, which is absent.'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are you not using the runtimelib here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To this and the above - error throwing was and still is a bit inconsistent - do you prefer to import all error helpers through runtimeLib or to turn everything into new Error('XP...')
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome! Let me know what the performance results do for the queries that are now supported by codegen!
This started out as implementing codegen for the not() function, but grew into a little bit more...
Things to note: