Overriding require causes eval to give wrong __FILE__ in certain circumstances

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: JRuby 1.2
  • Component/s: Core Classes/Modules
  • Labels:
    None

Description

So, say you have two files, foo1.rb and foo2.rb.
In foo1.rb:

eval(<<DEPS, binding, "deps")
class Object
  def require(file)
    super
  end
end
DEPS


def something(&block)
  eval("__FILE__", block.binding)
end

p eval("something { }", binding, "blah")

require 'foo2'

and in foo2.rb:

p  "./foo2.rb" == (something { })

This should produce the output

"blah"
true

but instead generates 

"foo1.rb"
false

Note that using eval to redefine require is just to avoid having three files. You could place the code in the string DEPS in a separate file and require that file, and the same effect would happen. It seems that the overriding of require in some way doesn't pass along the correct name information.

This breaks when using "dust" with ActiveSupport, and also breaks JtestR (which uses dust and ActiveSupport).

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Ola Bini added a comment -

Interestingly enough, if I change the code to

  alias old_require require
  
  def require(file)
    old_require(file)
  end

it produces the SAME problem. So it's not something with regards to the super or zsuper calls.

Show
Ola Bini added a comment - Interestingly enough, if I change the code to 
  alias old_require require
  
  def require(file)
    old_require(file)
  end
it produces the SAME problem. So it's not something with regards to the super or zsuper calls.
Hide
Permalink
Ola Bini added a comment -

I think I have fixed one of the issues on trunk. The eval version seems to be something else:

eval(<<DEPS, binding, "deps")
class Object
  alias old_require require
  
  def require(file)
    old_require(file)
  end
end
DEPS


def something(&block)
  eval("__FILE__", block.binding)
end

p eval("something { }", binding, "blah")

Probably just a missing setFile here too.

Show
Ola Bini added a comment - I think I have fixed one of the issues on trunk. The eval version seems to be something else: 
eval(<<DEPS, binding, "deps")
class Object
  alias old_require require
  
  def require(file)
    old_require(file)
  end
end
DEPS


def something(&block)
  eval("__FILE__", block.binding)
end

p eval("something { }", binding, "blah")
Probably just a missing setFile here too.
Hide
Permalink
Charles Oliver Nutter added a comment -

This case seems to have actually degraded:

$ jruby foo1.rb
""
false

I'm looking into it. The blank string seems to be reducible to the following case:

$ jruby -e "p eval 'eval %{__FILE__}, binding', binding, 'foo'"
""

It's the double binding that seems to cause it problems. Working on it.

Show
Charles Oliver Nutter added a comment - This case seems to have actually degraded: 
$ jruby foo1.rb
""
false
I'm looking into it. The blank string seems to be reducible to the following case: 
$ jruby -e "p eval 'eval %{__FILE__}, binding', binding, 'foo'"
""
It's the double binding that seems to cause it problems. Working on it.
Hide
Permalink
Charles Oliver Nutter added a comment -

After a night of hell, this is now working. I added a rubyspec that tests eval + binding + file in various configurations. I did not get it to match exactly what ruby does, since for requires in the current directory we still report _FILE_ as "file.rb" instead of "./file.rb", but that's a minor unrelated difference. Fixed in r9140.

Show
Charles Oliver Nutter added a comment - After a night of hell, this is now working. I added a rubyspec that tests eval + binding + file in various configurations. I did not get it to match exactly what ruby does, since for requires in the current directory we still report _FILE_ as "file.rb" instead of "./file.rb", but that's a minor unrelated difference. Fixed in r9140.

People

  • Assignee:
    Charles Oliver Nutter
    Reporter:
    Ola Bini
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: