-
-
Notifications
You must be signed in to change notification settings - Fork 925
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
1.7.26 regression: NoMethodError: private method `require' called for Kernel:Module in Sequel #4155
Comments
A workaround: require 'sequel'
module Sequel
def self.extension(*extensions)
extensions.each { |e| Kernel.send(:require, "sequel/extensions/#{e}") } # PATCH: avoid Kernel.require being private
end
end
Sequel.extension :core_extensions |
There is a similar issue with Bundler 1.13 and 1.13.1. The issue is also present in jRuby 1.7.24. I haven't checked other versions. See the referenced issue above. |
@perlun Perhaps your jruby-1.7.25 has bundler v1.12.5 installed? |
The changed Bundler code here, in the |
This is very strange. Kernel.require appears to be public and callable in all recent JRuby versions I tried. |
Ok, so the problem is definitely from rubygems/bundler@c144eb6#diff-f271319d553ee0af23e993e254a92c6cR293 In MRI, that causes visibility to be set to whatever is current for the frame, which is usually public. So the new In JRuby, because we associate visibility with the method rather than with the method table entry, the original Working with bundler folks on a fix now in rubygems/bundler#4975 |
We have proposed to bundler that they modify the FWIW, recent 9k (since 9.1.3.0) does not appear to have this problem. I fixed #3869 in 9b4e97b on master but did not backport that fix to 1.7. All versions of JRuby prior to 1.7.27 and 9.1.3.0 will have this bug. |
This is for #3869 and relates to the module_function change from and redefine it with a new visibility and implementation class. However the impl class never passed through to the contained method, preventing it from being used in super. This affected, for example, module_fuction singleton methods that need to super or methods transplanted using defined_method with a Method instance. The new logic always tries to dup the target method so it can be truly populated with the altered fields. This change fixed The previous commit, using cloning instead of construction for IR methods, works around the fact that there's no semi-transparent WrapperMethod to delegate its serial number to the wrapped method. Since in that case and in this one, the method's serial number was expected to be the same after duplication, the clone technique seems acceptable. jruby-1_7: Fixes #4155
Thanks for the footwork on this one, @olleolleolle and @jayjlawrence, you made it easy to track down. |
Thanks a lot for sorting this out @headius, @olleolleolle & @jayjlawrence - I'm happy to have been wrong this time (it wasn't really a regression in JRuby). Even happier that it has been fixed now. 👍 |
Something has gone broken in JRuby 1.7.26, causing the error below.
When I switch to JRuby 1.7.25, all is fine:
The failing code (https://github.com/jeremyevans/sequel/blob/master/lib/sequel/core.rb#L139) looks like this:
Any ideas or suggestions on what change in 1.7.26 could have been causing this?
/cc @olleolleolle, @sdahlbac
The text was updated successfully, but these errors were encountered: