[#35027] [Ruby 1.9-Bug#4352][Open] [patch] Fix eval(s, b) backtrace; make eval(s, b) consistent with eval(s) — "James M. Lawrence" <redmine@...>

Bug #4352: [patch] Fix eval(s, b) backtrace; make eval(s, b) consistent with eval(s)

16 messages 2011/02/01

[#35114] [Ruby 1.9-Bug#4373][Open] http.rb:677: [BUG] Segmentation fault — Christian Fazzini <redmine@...>

Bug #4373: http.rb:677: [BUG] Segmentation fault

59 messages 2011/02/06

[#35171] [Ruby 1.9-Bug#4386][Open] encoding: directive does not affect regex expressions — mathew murphy <redmine@...>

Bug #4386: encoding: directive does not affect regex expressions

9 messages 2011/02/09

[#35237] [Ruby 1.9-Bug#4400][Open] nested at_exit hooks run in strange order — Suraj Kurapati <redmine@...>

Bug #4400: nested at_exit hooks run in strange order

12 messages 2011/02/15

[ruby-core:35066] Re: [Ruby 1.9-Bug#4352] [patch] Fix eval(s, b) backtrace; make eval(s, b) consistent with eval(s)

From: Yusuke ENDOH <mame@...>
Date: 2011-02-03 04:19:22 UTC
List: ruby-core #35066
Hi,

2011/2/3 James M. Lawrence <redmine@ruby-lang.org>:
> The initial problem I encountered was
>
>  eval %{def g ; end}, nil, "(eval)", 99
>  p method(:g).source_location #=> ["(eval)", 99]
>
>  eval %{def f ; end}, binding, "(eval)", 99
>  p method(:f).source_location #=> ["prob.rb", 1]

Hmm.  It is indeed irritating for Kernel#eval to prefer implicit filename
of a binding to explicitly-specified filename.
This is because the current implementation is uncool, like:

  def eval(src, binding, filename = "(eval)", lineno = 1)
    filename = binding.filename if filename == "(eval)"
    ...
  end

Kernel#eval uses a string "(eval)" when the filename is not specified
explicitly.  And then, it replaces it with implicit filename of binding
when the given filename is equal to "(eval)" with string comparison.

Even so, I hesitate to change the behavior in 1.9.x for compatibility
reason.


> Since source_location claims to be "the ruby source filename and line
> number containing this proc", I was thinking that source_location
> could give the "true" location, ignoring the file/line "lies" passed
> to eval.

Honestly, I understand your expectation.  It is of course acceptable to
fix it in 2.0.  But it would require a major modification because the
current implementation itself does NOT know the "true" location.  The
information is discarded at the parse time.

-- 
Yusuke Endoh <mame@tsg.ne.jp>

In This Thread