module.nesting 在instance_eval/exec 或 module_eval/exec 中

Question

当我试图回答这个问题时，我想到了这个问题。以下是预期行为：

module A
  p Module.nesting
end
# => [A]

但以下情况：

A.instance_eval{p Module.nesting}
A.instance_exec{p Module.nesting}
A.module_eval{p Module.nesting}
A.module_exec{p Module.nesting}

全部返回 []。为什么这些不能像上面那样工作？

附加问题

Mu太短了，提出了一个有趣的观点。如果这是正确的，那么 Module.nesting 将是依赖于文字上下文的方法和变量之一，例如 Method#source_location、__FILE__。这种理解正确吗？如果是这样，有人可以提供这些依赖于文字上下文的方法/变量的清单吗？我觉得还是很有参考价值的。

Answer 1

警告：这有点长而且漫无目的。由于文档有点单薄，因此似乎有必要浏览一下 Ruby 源代码。如果您不关心香肠的制作方法，请随意跳到最后。

---

1.9.2 Module.nesting 在 eval.c 中实现如下：

static VALUE
rb_mod_nesting(void)
{
    VALUE ary = rb_ary_new();
    const NODE *cref = rb_vm_cref();

    while (cref && cref->nd_next) {
        VALUE klass = cref->nd_clss;
        if (!(cref->flags & NODE_FL_CREF_PUSHED_BY_EVAL) &&
            !NIL_P(klass)) {
            rb_ary_push(ary, klass);
        }
        cref = cref->nd_next;
    }
    return ary;
}

我不太了解 Ruby 内部结构，但我读了 while 像这样循环：从 cref 链表中提取与类似类的事物关联但不是来自 eval 的所有节点。 NODE_FL_CREF_PUSHED_BY_EVAL 位仅在此处设置：

/* block eval under the class/module context */
static VALUE
yield_under(VALUE under, VALUE self, VALUE values)

更多的 grep 和阅读表明 instance_eval 最终会经历 yield_under。我将检查 instance_exec、module_eval 和 module_exec 作为读者的练习。无论如何，instance_eval 似乎已从 Module.nesting 列表中明确排除；然而，这比其他任何事情都更让人分心，它只是意味着您不会看到评估提到的内容。

所以现在的问题是“NODE 和 rb_vm_cref() 到底是什么？”。

如果您查看 node.h，您会看到一堆针对各种 Ruby 关键字和语言结构的 NODE 常量：

• NODE_BLOCK
• NODE_BREAK
• NODE_CLASS
• NODE_MODULE
• NODE_DSYM
• ...

所以我猜测 NODE 是指令树中的一个节点。这很符合我的

Module.nesting 似乎更多的是与解析器对话

Module.nesting 似乎更多的是在评论中 猜想。但无论如何我们都会继续前进。

rb_vm_cref 函数只是 vm_get_cref 的包装器，而 vm_get_cref 又是 vm_get_cref0 的包装器。 vm_get_cref0 到底是什么？全部是这样的：

static NODE *
vm_get_cref0(const rb_iseq_t *iseq, const VALUE *lfp, const VALUE *dfp)
{
    while (1) {
        if (lfp == dfp) {
            return iseq->cref_stack;
        }
        else if (dfp[-1] != Qnil) {
            return (NODE *)dfp[-1];
        }
        dfp = GET_PREV_DFP(dfp);
    }
}

函数的所有三个参数都直接来自此控制框架：

rb_control_frame_t *cfp = rb_vm_get_ruby_level_next_cfp(th, th->cfp);

iseq 似乎是一个指令序列，lfp 和 dfp 是帧指针：

VALUE *lfp;                 // cfp[6], local frame pointer
VALUE *dfp;                 // cfp[7], dynamic frame pointer

cref_stack 的定义是相关的：

/* klass/module nest information stack (cref) */
NODE *cref_stack;

因此看起来您正在从 rb_vm_cref 中获取某种调用或嵌套堆栈。

---

现在回到手头的具体细节。当您执行此操作时：

module A
  p Module.nesting
end

您将在 cref 链接列表中拥有 module A（经过过滤以生成 Module.nesting 结果数组）因为您还没有到达end。当您说这些时：

A.instance_eval { puts Module.nesting }
A.instance_exec { puts Module.nesting }
A.module_eval   { puts Module.nesting }
A.module_exec   { puts Module.nesting }

您将不再有 cref 中的 module A 因为您已经点击了 end 弹出的 module A 离开堆栈。但是，如果您这样做：

module A
  instance_eval { puts Module.nesting.inspect }
  instance_exec { puts Module.nesting.inspect }
  module_eval   { puts Module.nesting.inspect }
  module_exec   { puts Module.nesting.inspect }
end

您将看到以下输出：

[A]
[A]
[A]
[A]

因为模块 A 尚未关闭（并从 cref 弹出）。

最后，Module.nesting 文档 说的是：

返回调用点嵌套的模块列表。

我认为这个陈述与内部审查相结合表明 Module.nesting 实际上依赖于调用它的特定文字上下文。

如果任何在 Ruby 内部有更多经验的人有任何需要添加的内容，我可以将其作为社区 wiki 交给 SO 社区。

---

更新：所有这些都适用于class_eval以及module_eval，它也适用于1.9.3以及它1.9.2.