Buggy IR built for const lookup instr inside a stabby lambda

[subbuss]

Reproducible with this simple snippet:

class C
  class D; end
end

-> { C::D.new }.call

The IR built for the lookup of C is:

2014-12-06T17:06:48.228+05:30: InterpretedIRBlockBody: CFG:
BB [1:CL1_LBL_2:0]
BB [2:CL1_LBL_3:0]
        line_num(4)
        %v_0 = search_const(C, %v_1, no-private-consts=false)

Notice the %v_1 use without a corresponding definition for it.

This is the source of the two travis-core failures seen in https://travis-ci.org/travis-ci/travis-core/jobs/42825525

[subbuss]

@headius @enebo This bug opens up the potential for cleanup that I had been considering for a while. I had introduced the scope / module variable stuff long back so that we can exploit static information where available. However, as part of removing IRScope references for JIT, that basic intention has been a bit obscured.

In any case, will take a look at this later tonight and fix up the mixing initialization.

[subbuss]

The bug is fixed, but let us chat later about cleaning up the CurrentScope/CurrentModule uses. I have a feeling get rid of the temporary variables and simplify some of that old code.

[enebo]

Awesome thanks subbu. You get back on what day?

-Tom

On Sat, Dec 6, 2014 at 6:27 AM, subbuss notifications@github.com wrote:

The bug is fixed, but let us chat later about cleaning up the
CurrentScope/CurrentModule uses. I have a feeling get rid of the temporary
variables and simplify some of that old code.

—
Reply to this email directly or view it on GitHub
#2284 (comment).

blog: http://blog.enebo.com twitter: tom_enebo
mail: tom.enebo@gmail.com