On Mon Jun 12 14:33:40 2023 +0000, Jacek Caban wrote:
It doesn't really belong here, it's a per-call property and I think that it fits call frame. The whole solution still suffers from over-allocating arguments object. Another solution would be to store `function_code_t` (we already store scope index) as well as detached locals buffer here. Arguments object could then just store a reference to scope chain. That would need other solutions for addressing arguments. Maybe we have a reason to treat scope as an object in more aspects after all. You could use that to expose locals using `idx_put()`/`idx_get()`, for example. Since applications will never use this as an object directly, names associated with dispids don't matter so the same mechanism could be used in the future for local variables as well. Potentially, variable object is needed only for `with` statement and extendable scopes. Eventually, having a static view of the whole scope chain with easy to identify bail outs could give nice performance opportunities. For example, we could move more name lookups to the compiler and entirely skip them in runtime. It's obviously not related to your bug. It's fine to implement only arguments part, but I'd prefer a solution that does not make future changes harder.
So to summarize, I move all detached scope locals to the scope's jsdisp, accessed by index (from lookup_local). If so, what would the point of "detached locals buffer" be? Or was that just an alternative?
I mean I could store the local's value itself directly into the scope's props, no need to keep a separate buffer, I think. I'll only have to map indexed args into props with idx_get/put, and for arguments with "no name" (shadowed by duplicated names, or extra args passed to a func) maybe just store them with prop name = index, since locals can't have names starting with a digit…
I think it should work, unless I'm missing something.