Allow Proxy target and handler to be Proxy too

[svaarala]

Up to now Duktape has intentionally rejected a Proxy as either a Proxy target or a Proxy handler object; both cases cause more potential for native recursion and are relatively rare in practice. ES2015+ does not place such a limitation on Proxies. This pull removes the current limitation and allows Proxies as both target and handler.

Tasks:

• Remove Proxy check for target/handler in Proxy creation
• Proxy chain support for getprop
• Proxy chain support for putprop
• Proxy chain support for delprop
• Proxy chain support for hasprop
• TBD: enumeration etc
• Testcase coverage
• Releases entry

This is currently work in progress, to be merged after 2.3.

[fatcerberus]

I’m actually a bit surprised they allow a Proxy for the handler. Proxy-of-Proxy makes some sense, but a Proxy’d handler doesn’t seem as useful.

[svaarala]

I think it's just allowed by default: it's not explicitly rejected even though it may not be very useful in practice.

[fatcerberus]

Yeah, makes sense. It just seems like something that might want to be rejected explicitly simply to avoid all the potential edge cases it creates. But thinking about it, I suppose that the same pitfalls apply to recursive proxies so disallowing a Proxy as handler doesn’t really buy you anything in that regard.

[svaarala]

In practice the main difficulties for Duktape would be:

• Additional paths for native recursion. Since native stack depth is controlled via the native callstack limit, it's problematic that this particular form of recursion might happen outside of that control (i.e. without function calls and thus not controlled by the limit). However, it should be possible to do the Proxy chain resolution without native recursion (even tail recursion) so this is solvable, and the pull currently does so.
• Potential for Proxy target/handler loops. These would be possible in principle, as far as the data structures are concerned, but because all Proxy instances are created with the target/handler being an already created object, it's not possible to create loops in practice. So this is also a non-issue.
• Chains of billions of Proxies might cause performance issues and be problematic for the execution timeout mechanism, and such chains could be created from plain Ecmascript code too. So maybe long Proxy chains should invoke the timeout check from time to time. There are similar potential issues for effectively bypassing the execution timeout with other script-accessible features too (e.g. huge array joins) so it wouldn't be the only such potential around.

There may be more corner cases here and there though.