-
-
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
ActiveSupport EventedFileUpdateChecker wrong number of arguments in JRuby #3733
Comments
I get a different error for this now. I'm not sure if we're getting farther or not as far:
|
Ok wow, when I actually try this with 9.0.5 I can even get a weird error with a simple case taken directly from the code:
Something's getting routed weird in |
I think that is an issue with the apostrophes.
|
Oh nice catch...continuing to investigate. |
I can reproduce with
So it seems like it's having some trouble with the incoming argument list actually not matching the method's arity. The JavaMethod line 604 here is basically the error case when a 1 or 2-argument target does not receive 1 or 2 arguments. The line of code triggering this obviously does pass two arguments, so we have a conundrum. |
Ok, the main issue here is actually caused by our poor support for refinements. Earlier in the PathHelper class, where this method class PathHelper
using Module.new {
refine Pathname do
def ascendant_of?(other)
self != other && other.ascend do |ascendant|
break true if self == ascendant
end
end
end
}
def xpath(path)
Pathname.new(path).expand_path
end
def normalize_extension(ext)
ext.to_s.sub(/\A\./, '')
end As a result of this I modified it to just directly monkey-patch, and @tenderlove is working on a patch to just remove the gratuitous use of refinements here. Either way I can get past this point. Here's my change: class PathHelper
class ::Pathname
def ascendant_of?(other)
self != other && other.ascend do |ascendant|
break true if self == ascendant
end
end
end This leads to a new error that seems to be an issue in dependency resolution:
The line that triggers the eventual require of "listen" appears to be a super inside a block, which may be the same issue as #3643 (in that bug, a super method seems to "disappear" at runtime). Because this will get fixed for Rails 5 final (assuming @tenderlove's fix is not reverted), this is now just a refinements bug and may be punted to 9.1.1. |
Ok, I figured out the weird arity error...RefinedCachingCallSite was failing to pass on varargs when dispatching to the original method. We still have refinements issues that prevent this code from working, but that's one fix at least! |
This fixes the arity issue in #3733, but there's other refinement bugs preventing the referenced code from working.
After fixing the arity issue, we are back to a more standard refinement bug, where it can't see the added method at call sites where it should. Here's the error:
And the code that triggers it (with Pathname refined as shown in my earlier comment): # Given a collection of Pathname objects returns the longest subpath
# common to all of them, or +nil+ if there is none.
def longest_common_subpath(paths)
return if paths.empty?
lcsp = Pathname.new(paths[0])
paths[1..-1].each do |path|
until lcsp.ascendant_of?(path)
if lcsp.root?
# If we get here a root directory is not an ascendant of path.
# This may happen if there are paths in different drives on
# Windows.
return
else
lcsp = lcsp.parent
end
end
end
lcsp
end This remaining bug may be duplicated by other refinement issues, like #3548. |
Steps to reproduce
rails _5.0.0.beta3_ new rails_5_test --api
Entire Gemfile:
source 'https://rubygems.org'
ruby "2.2.3", { :engine => "jruby", :engine_version => "9.0.5.0" }
gem 'rails', '>= 5.0.0.beta3', '< 5.1'
Bundle and Console:
bundle install
rails c
Actual behavior
Get this error:
System configuration
Rails version: 5.0.0.beta3
Ruby version: JRuby 9.0.5.0
Additional Info
This bug is also shown here: rails/rails#23975
I'm reporting this bug here because of the comment left by @jensnockert who said:
If you replace the 'offending' code with some string manipulation you get the following stacktrace which is probably closer to revealing the JRuby bug behind this.
The text was updated successfully, but these errors were encountered: