-
Notifications
You must be signed in to change notification settings - Fork 191
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
Streamline append VM implementation and remove enums #1643
Conversation
Historically, many of these enums used `const enum`s, which at least had the benefit of being compiled away at build time. We've now moved to mostly normal `enum`s, which are both less efficient than normal constants, and a relic of an earlier TypeScript era before literal types. This PR moves all enums to normal constants, and creates types for the constant values when the code needs them.
@@ -7,7 +7,8 @@ export { | |||
s, | |||
unicode, | |||
} from './lib/builder/builder'; | |||
export { Builder, type BuilderStatement } from './lib/builder/builder-interface'; | |||
export { type BuilderStatement } from './lib/builder/builder-interface'; | |||
export * from './lib/builder/constants'; |
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.
can we export explicitly, instead of export *
?
From a "knowing what is here" perspective, *
feels like an unneeded indirection, and risks leaking things we don't actually want to expose as public API.
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.
there is a lot in here: https://github.com/glimmerjs/glimmer-vm/pull/1643/files#diff-f881a95cdbb07c9ee63e2f6fca320f7d00323b27434dbee753f4cffb38d30a85R6
does it all need to be public API?
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.
It was all public API but sucked into the Builder
enum. And the codebase already does a lot of export *
.
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.
is this file generated?
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.
Negative.
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.
it's not too bad
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.
I'm surprised how much getting rid of enums helps with general readability
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.
We have a significant perf regression for some reason.
This PR begins the process of incrementally implementing many of the improvements in the error recovery branch.
I'm going to start with the easy stuff and work my way up to more complicated parts of the implementation, and in that spirit, this PR has two changes:
debug
field pattern. This simplifies the implementation and also makes it possible to consolidateInternalAppendVM
into the normalVM
. The benefit of the "opcode-only" subset of the VM was waning anyway, and most of the remaining distinction had to do with private implementation details that are no longer present in theVM
interface because they're now implemented using private fields.const enum
andenum
with normal constants and literal types. There was a good reason for us to useconst enum
when we originally made the decision. But the dynamics have changed. Between (a) the fact that we can't reliably thatconst enum
will be compiled away anymore, and (b) the fact that TS now has literal types, using normal constants and literal types is a better choice.