Non-existent method being reported

[guilhermesimoes]

This is a small code sample that I extracted from the ffi gem's spec:

describe "Callback" do
  module LibTest
    extend FFI::Library
  end
end

I'm not sure if this is a flog or sexp_processor issue, but here's what's happening when I run flog:

$ flog -a callback_spec.rb
3.0: flog total
1.5: flog/method average

2.0: describe(Callback)::LibTest#Callback
1.0: describe#Callback                callback_spec.rb:1

Basically, calling extend somehow leads to a Callback method being reported. Also, since this method doesn't exist, sexp_processor's method_locations doesn't include it, which is why the flog report does not include the file and line of the method.

If you could just point me in the right direction, I might be able to fix this.

[zenspider]

I'm confused as to what the problem is for you. What are you expecting to see, and what's different from that?

Dynamically generated code doesn't have a file/line. Is that the problem? Or is it something else?

[guilhermesimoes]

But is there code being dynamically generated? This is just a single file, that extend call is doing nothing. You could call extend Whatever and the result would be the same. LibTest doesn't have a Callback method.

Basically, I'd expect not to see the line describe(Callback)::LibTest#Callback.

[UncleGene]

To clarify OP complaint (note that sample is a complete file, so describe does not generate anything)

flog -m sample.rb
     3.0: flog total
     1.5: flog/method average

     2.0: describe(Callback)::LibTest#Callback

If you look at sexp, there is no defn, but it is still reported as a method

 s(:iter,
 s(:call, nil, :describe, s(:str, "Callback")),
 s(:args),
 s(:module,
  :LibTest,
  s(:call, nil, :extend, s(:colon2, s(:const, :FFI), :Library))))

[zenspider]

That's because flog treats top-level forms of iter as "methods". Rake tasks, tests, etc.

[zenspider]

% flog blah.rb
     2.0: flog total
     2.0: flog/method average

     2.0: task#woot                        blah.rb:1

from

task :woot do
  sh "echo woot"
end

[zenspider]

So, yeah, that's the "problem" here. The top level describe is being reported and the inner module is too.

[guilhermesimoes]

That makes perfect sense. Just like

$ flog -a test.rb
1.0: flog total
1.0: flog/method average

1.0: describe#Callback                test.rb:1

from

describe "Callback" do
end

This is fine.

But go back to my original example. extending something inside the module somehow leads the top level iter to be considered simultaneously a method of the describe block and a method of the inner module.

Is this really intended? The "method" is even missing its file and line.

[zenspider]

I suspect the problem is that it should say:

2.0: describe(Callback)::LibTest#extend

instead of:

2.0: describe(Callback)::LibTest#Callback

[guilhermesimoes]

I guess that would make sense.

From my limited testing, this also happens with other methods like include, private and attr_reader.

[zenspider]

They're method calls, so yes.

[zenspider]

This is a problem with MethodBasedSexpProcessor#in_klass in sexp_processor. I've fixed it and will release it soon.

[guilhermesimoes]

Superb! Sorry if my bug report wasn't clear. Thanks! 😄

[guilhermesimoes]

Hey @zenspider, just to clarify, has this been fixed?

With the most recent version of sexp_processor (4.4.4), flog no longer reports:

2.0: describe(Callback)::LibTest#Callback

but instead reports:

2.0: describe(Callback)::LibTest#none

You said this should probably be reported as extend, no? And shouldn't it also include its file and line number?

[zenspider]

Here's what I see for the following source:

describe "OK" do
  extend FFI::Library
end

describe "Bad" do
  module LibTest
    extend FFI::Library
  end
end

Running flog on that w/ --details gives me:

% rake debug F=bug04.rb D=1
     6.6: flog total
     2.2: flog/method average

     3.3: describe#OK                      bug04.rb:1
     2.2:   extend
     1.1:   describe

     2.2: describe(Bad)::LibTest#none
     2.2:   extend

The thing that's confusing is the none part, but that's because you've got this wierd mix of describe (which is treated like a method) and an inner module (which is treated like a module/class). Code inside of just the describe would be treated like a call within that block, and would look like "OK" above.

Code inside the module looks like attr_accessor and other such class/module-level calls and are assigned to "none" since you're not currently in a method.

Flog doesn't know that describe is essentially a class definition. It just knows that it is a method call and is being passed a block in such a way that it looks like a DSL, so it records it like a method definition.

I guess we could try to come up with some logic to try to determine the context better... but I think a module inside a method inside a module inside a method is just gonna be confusing no matter what you try to do to the logic.