8000
We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
There was an error while loading. Please reload this page.
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
6860ed7
dcba32e
30cb8cd
6af0a5d
039efbf
2fd8822
14bbd50
00a2495
f01dff5
71ee089
966da1a
7c94591
2c76046
d0f29f8
001c418
05caa7e
8d445ae
c1f3034
e2f376b
53c204e
e0ba8bf
f7a54d7
6ae9e6e
34aa393
e144db3
029bf07
fa3135f
445f20b
32b4ac0
0ef4da7
7d19466
99e8ec6
c08dbdb
c6dfeec
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Would it be possible to have the generator also build a header with all of these lines? You would need to run the generator at least once before the red squiggles go away, but then we don't have to worry about manually maintaining this blob of stuff.
Sorry, something went wrong.
Yeah, this part of the tooling is kind of annoying. But having the generator also update bytecodes.c seems sneaky (and slightly dangerous).
Is this actually needed? Or just the "right" thing to do?
Without it the assert(EMPTY()) on the next line fails. I'm kind of hoping that when asserts are off, the compil 8486 er sees that the stack pointer is dead at this point and won't bother to generate code for it. Then again, the original had POP() which also adjusts the stack pointer.
assert(EMPTY())
POP()
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.