Closure tracking

[hmdne]

The closures make everything harder for how Opal is right now.

Consider this theoretical code:

proc { a = (true and next); 6 }

What does this proc return? 6. Why? Because a closure stands in a way and next is ONLY compiled to return. A lot more issues - albeit you really need to try to break it - but some existing code may show deficiencies, eg. when you get two returners entangled.

So I propose to track the closures and use this knowledge to correctly dispatch the breakers/nexters/returners/retriers. If we get a closure in the way - we need to use exceptions.

Commit description of the finalized patch:

    This adds closure awareness to Opal. Previously, some control flow
    instructions were working based on the most common situation and
    in certain situations we got that wrong. The previous implementation
    also led to a lot of scattered around code and a lot of logic
    duplication. My view is that this patch improves maintainability
    of our codebase a lot and allows for further improvements based on
    the new mini-DSL. Unfortunately, one of the downsides of this code
    is that runtime performance is slightly decreased.

Also, I have verified that all linked issues are fixed by this patch.

[hmdne]

This now implements both break and next correctly. It is still too early to merge and performance got quite a heavy hit. But to ensure everything works correctly, this patch still needs some time.

[hmdne]

The question here - I may have that patch finished until next week. Do we get this for 1.6, or do we postpone it to "1.7" whatever the next release may be.

[hmdne]

A problem found with Opal-RSpec working branch:

[user@localhost opal]# bin/opal -e 'def x; lambda do; return 3; end; end; p x.()'
[Opal]: Zlib::BufError; retrying
<internal:corelib/runtime.js>:2969:5:in `x': unexpected return (Exception)
	from -e:1:1:in `x'
	from -e:1:41:in `undefined'
	from <internal:corelib/runtime.js>:2805:7:in `<main>'
	from -e:1:1:in `null'
	from node:internal/modules/cjs/loader:1105:14:in `Module._compile'
	from node:internal/modules/cjs/loader:1159:10:in `Module._extensions..js'
	from node:internal/modules/cjs/loader:981:32:in `Module.load'
	from node:internal/modules/cjs/loader:822:12:in `Module._load'
	from node:internal/modules/run_main:77:12:in `executeUserEntryPoint'
	from node:internal/main/run_main_module:17:47:in `undefined'
[user@localhost opal]# ruby -e 'def x; lambda do; return 3; end; end; p x.()'
3
[user@localhost opal]# 

[janbiedermann]

push_closure if has_rescue_else?

maybe

[hmdne]

unfortunately no... has_rescue_else? can be called only after we have traversed thru all the child nodes. as a followup to this, I plan to mark the throwers using a rewriter, replacing the current measures and the BreakFinder rewriter

[janbiedermann]

pop_closure if has_rescue_else?

maybe?

[hmdne]

• toplevel return breaks with this patchset

[elia]

As always great to see all those specs go away 🎉