Hi On 1/13/26 23:19, Larry Garfield wrote:
Once those issues are addressed, I think we're nearly able to take CMs to a vote. (If anyone else wants to weigh in on some other part as well, even if it's just a voice of support/approval, now is the time.)
Something I noticed while reviewing the block scoping RFC: Both RFCs come with new OPcodes in the engine.
This can have an impact on extensions that work with OPcodes, for example profilers and debuggers. Block scoping already mentioned this in the RFC Impact section, but the context manager RFC does not.
For block scoping the two OPcodes are relatively straight-forward assignments which should (hopefully) be easy to take into account for a debugger. For context managers there seems to be more associated logic to set up the scope within the ZEND_INIT_USING OPcode, which might be more troublesome for debuggers to correctly reason about when stepping through the code (e.g. with the $__RETURN_VALUE meta variable or whatever it is called). Perhaps Derick can provide insight here?
Looking at that OPcode I'm also seeing the initialization of the `ResourceContextManager` class. In the RFC it is called `ResourceContext` and it is non-final there (final in the implementation). This is an inconsistency that should be fixed. For that one I was also wondering if it is possible to directly initialize it in userland (the constructor seems to be public) and if it will then behave as expected. I assume the answer is yes to both, but it would be useful for the RFC to clarify this.
Best regards Tim Düsterhus
