看看这个简单的 Ruby 类:

require 'byebug'

class Foo
  def run
    byebug

    puts defined?(bar)
    puts bar.inspect

    bar = 'local string'

    puts defined?(bar)
    puts bar.inspect
  end

  def bar
    'string from method'
  end
end

Foo.new.run

运行此类时，可以在调试器的控制台中观察到以下行为:

    $ ruby byebug.rb

    [2, 11] in /../test.rb
        2:
        3: class Foo
        4:   def run
        5:     byebug
        6:
    =>  7:     puts defined?(bar)
        8:     puts bar.inspect
        9:
       10:     bar = 'local string'
       11:

在断点处，调试器返回以下值:

    (byebug) defined?(bar)
    "local-variable"
    (byebug) bar.inspect
    "nil"

请注意 - 尽管调试器的断点在 #5 行- 它已经知道会有一个局部变量bar在 #10 行中定义这将影响方法 bar并且调试器实际上无法再调用 bar方法。此时不知道的是字符串 'local string'将分配给 bar .调试器返回 nil对于 bar .

让我们继续 Ruby 文件中的原始代码并查看其输出:

    (byebug) continue
    method
    "string from method"
    local-variable
    "local string"

在运行时行 #7 Ruby 仍然知道 bar确实是一种方法，它仍然可以在 #8 行中调用它.然后线 #10实际上定义了局部变量，该变量以相同的名称隐藏了方法，并且 tTherefore Ruby 在行 #12 中返回了预期的结果和 #13 .

问题:为什么调试器返回的值与原始代码不同？似乎可以预见 future 。这被认为是功能还是错误？这种行为是否记录在案？

最佳答案

无论何时您进入调试 session ，您实际上都在针对代码中那个位置的绑定(bind)执行 eval。下面是一段更简单的代码，它重现了让您抓狂的行为:

def make_head_explode
  puts "== Proof bar isn't defined"
  puts defined?(bar)   # => nil

  puts "== But WTF?! It shows up in eval"
  eval(<<~RUBY)
    puts defined?(bar) # => 'local-variable'
    puts bar.inspect   # => nil
  RUBY

  bar = 1
  puts "\n== Proof bar is now defined"
  puts defined?(bar)   # => 'local-variable'
  puts bar.inspect     # => 1
end

当方法 make_head_explode 被提供给解释器时，它被编译成 YARV 指令，一个本地表，它存储关于方法的参数和方法中所有局部变量的信息，以及一个捕获表如果存在，则在方法中包含有关救援的信息。

此问题的根本原因在于，由于您在运行时使用 eval 动态编译代码，Ruby 也会将包含未设置变量 enry 的本地表传递给 eval。

首先，让我们使用一个非常简单的方法来演示我们期望的行为。

def foo_boom
  foo         # => NameError
  foo = 1     # => 1
  foo         # => 1
end

我们可以通过使用 RubyVM::InstructionSequence.disasm(method) 提取现有方法的 YARV 字节码来检查这一点。请注意，我将忽略跟踪调用以保持说明整洁。

RubyVM::InstructionSequence.disasm(method(:foo_boom)) 的输出更少跟踪:

== disasm: #<ISeq:foo_boom@(irb)>=======================================
local table (size: 2, argc: 0 [opts: 0, rest: -1, post: 0, block: -1, kw: -1@-1, kwrest: -1])
[ 2] foo
0004 putself
0005 opt_send_without_block <callinfo!mid:foo, argc:0, FCALL|VCALL|ARGS_SIMPLE>, <callcache>
0008 pop
0011 putobject_OP_INT2FIX_O_1_C_
0012 setlocal_OP__WC__0 2
0016 getlocal_OP__WC__0 2
0020 leave                                                            ( 253)

现在让我们遍历跟踪。

local table (size: 2, argc: 0 [opts: 0, rest: -1, post: 0, block: -1, kw: -1@-1, kwrest: -1])
[ 2] foo

我们可以在这里看到 YARV 已经确定我们有局部变量 foo，并将它存储在索引 [2] 处的本地表中。如果我们有其他局部变量和参数，它们也会出现在该表中。

接下来，当我们尝试在分配之前调用 foo 时，我们会生成指令:

  0004 putself
  0005 opt_send_without_block <callinfo!mid:foo, argc:0, FCALL|VCALL|ARGS_SIMPLE>, <callcache>
  0008 pop

让我们剖析这里发生的事情。 Ruby 根据以下模式编译 YARV 的函数调用:

• 推送接收者:putself，指函数的顶层作用域
• 推送参数:这里没有
• 调用方法/函数:函数调用(FCALL)到foo

接下来，我们将在 foo 成为全局变量后进行设置:

0008 pop
0011 putobject_OP_INT2FIX_O_1_C_
0012 setlocal_OP__WC__0 2
0016 getlocal_OP__WC__0 2
0020 leave                                                            ( 253)

要点:当 YARV 手头有完整的源代码时，它知道何时定义了局部变量，并像您期望的那样将对局部变量的过早调用视为 FCALL。

现在让我们看一下使用 eval

def bar_boom
  eval 'bar'     # => nil, but we'd expect an errror
  bar = 1         # => 1
  bar
end

RubyVM::InstructionSequence.disasm(method(:bar_boom)) 的输出更少跟踪:

== disasm: #<ISeq:bar_boom@(irb)>=======================================
local table (size: 2, argc: 0 [opts: 0, rest: -1, post: 0, block: -1, kw: -1@-1, kwrest: -1])
[ 2] bar
0004 putself
0005 putstring        "bar"
0007 opt_send_without_block <callinfo!mid:eval, argc:1, FCALL|ARGS_SIMPLE>, <callcache>
0010 pop
0013 putobject_OP_INT2FIX_O_1_C_
0014 setlocal_OP__WC__0 2
0018 getlocal_OP__WC__0 2
0022 leave                                                            ( 264)

我们再次在索引 2 处的局部变量表中看到一个局部变量 bar。我们还有以下 eval 指令:

0004 putself
0005 putstring        "bar"
0007 opt_send_without_block <callinfo!mid:eval, argc:1, FCALL|ARGS_SIMPLE>, <callcache>
0010 pop

让我们剖析这里发生的事情:

• 推送接收者:又是putself，指的是顶层函数作用域
• 推送参数:“bar”
• 调用方法/函数:函数调用(FCALL)到eval

之后，我们对 bar 进行了预期的标准赋值。

0013 putobject_OP_INT2FIX_O_1_C_
0014 setlocal_OP__WC__0 2
0018 getlocal_OP__WC__0 2
0022 leave                                                            ( 264)

如果我们这里没有 eval，Ruby 就会知道将对 bar 的调用视为函数调用，这会像我们之前的代码那样崩溃例子。但是，由于 eval 是动态评估的，并且其代码的指令直到运行时才会生成，因此评估发生在已经确定的指令和本地表的上下文中，该表包含幻影 bar 你看到的。不幸的是，在这个阶段，Ruby 并不知道 bar 是在 eval 语句“下方”初始化的。

要深入了解，我建议阅读 Ruby Under a Microscope和 Ruby Hacking Guide's评估部分。

关于ruby - 为什么 Ruby 调试器在运行时返回的值与代码不同？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/42697187/