Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Make autoload dynamically dispatch to require. Fixes #5403. #5404
@headius I don't know if this helps, but it looks like the assertion is testing that there are no warnings and the warnings are coming from RubyGems (this is from the test failure output):
It could be that disabling RubyGems will fix this test (addressing the warning in RubyGems may have nothing to do with JRuby).
Ok, so the problem here is the same thing as #3656, where an explicit require of an autoloaded file does not remove that autoload from firing again. Here's a trivial reproduction:
class A autoload :B, 'atest/b' end require 'atest/b'
class A::B end
The normal require starts the process of loading atest/b.rb. That file then attempts to (re)open A::B, which triggers the autoload detection. Autoload does not check if there's a require of that file already in progress before proceeding to dynamically invoke
I am working through CRuby logic for this. I believe what's missing is the
Yes, that's basically the issue. This all feeds back into us not having the same search and caching capabilities for load paths, expanded paths, and loaded features that MRI does.
I ported over the "loaded_feature_path" method and added a loop over all currently-loading scripts, as is done in the rb_feature_p function. CRuby checks for an existing feature in the following ways, if I'm following right:
So basically, we're missing most of the search logic that MRI does during rb_feature_p because we don't walk through the whole load path (with pre-expanded paths) and look for the long name.
See also #2794.
@enebo It's time we bit the bullet and matched their searches, at least, which will likely necessitate incorporating the same caching.
Rebased atop master with the