-
Notifications
You must be signed in to change notification settings - Fork 66
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
Explicit preparation phase without STATE #333
base: master
Are you sure you want to change the base?
Conversation
Since git 2.23 .gitignore that is a symbolic link is ignored. I made them explicit now (though I'm not sure they're even needed)
So simplify the return value.
Our goal is to get pure functions that don't affect STATE.
It turns out the dropping and relocking state in the right order is essential for the test suite to even complete...
Note that prepare isn't pure here as it mutates a class. We may want to rearrange things later.
…t's state related. It's still going to need revision later as it depends on state modification to work. The class should only be modified once it is explicitly registered.
…stream generation.
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.
Thank you for the PR!
After having a quick look this looks fine to me. Would like to do some testing before merging, as this affects core logic.
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 you check if this mr builds on top of current master. A little confused seeing these changes again.
State (through the static
STATE
) is modified and used throughout ext-php-rs, but it's giving rise to various problems during development - the order in which the run compiler runs things is not guaranteed, and it appears that at least in some cases (in rust analyzer?) the system gets confused. See #327.To make this go away, I want to introduce an explicit registration mode. This is a preparatory refactor (which should introduce no behavioral changes) to help go into this direction, unweaving STATE access and modification from generation of token streams. It doesn't do anything by itself, but hopefully clears the ground.
The next step would be to see whether we can defer building and registration to a later phase. In particular, the
ClassBuilder
build
method registers as a side-effect, though the other builders don't appear to do so.This is a step in the direction of #329