Fix evaluation order for toplevel bindings in classes with local opens #13179
Conversation
| @@ -215,6 +215,9 @@ let rec build_object_init_0 | |||
| Tcl_let (_rec_flag, _defs, vals, cl) -> | |||
| build_object_init_0 | |||
| ~scopes cl_table (vals@params) cl copy_env subst_env top ids | |||
| | Tcl_open (_descr, cl) -> | |||
| build_object_init_0 | |||
| ~scopes cl_table params cl copy_env subst_env top ids | |||
| | _ -> | |||
There was a problem hiding this comment.
Having an exhaustive list of constructor instead of _ would probably prevent future instances of the bug
There was a problem hiding this comment.
I don't agree. If we followed the specification from the manual to the letter, then only Tcl_let should trigger the lifting, and this PR is actually introducing a bug. I felt that the spirit of the specification should allow Tcl_open too, so I opened this PR, but in my mind it's clear that those two cases are exceptions. If a constructor gets added, it should fall into the catch-all, unless we specifically want to extend the toplevel optimisation to it again (and I argue in #13178 that this optimisation is not even a good idea).
There was a problem hiding this comment.
If a constructor gets added, it should fall into the catch-all, unless we specifically want to extend the toplevel optimisation to it again
Having the compiler complain gives the opportunity to think about whether to extend the optimization or not. Having a diff here when adding a constructor will make this decision explicit to other reviewers as well.
This PR fixes the issue with local opens in classes, as described in #13178.
I've added the examples from that issue in this PR, with their current semantics.