-
-
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
java.lang.IncompatibleClassChangeError in 9.0.0.0 rc1 #3056
Comments
I think between pre1 and pre2 we added logic to reify blocks into procs only if they end up being used. So this is likely still fallout from that. |
HEH. I had marked this a JIT bug but in fact it is an IR bug and our block reification logic. I do not have this localized yet but the general way to reproduce without JIT is:
The code in question croaking is: def create_table_generator(&block)
super do
extend CreateTableGeneratorMethods
@validations = []
instance_eval(&block) if block
end
end |
Reduced: module Base
def foo
yield
end
end
module Doo
include Base
def foo(&block)
super do
instance_eval(&block) if block
end
end
end
class Mine
include Doo
end
Mine.new.foo { puts "AAAA" } Run with:
|
Ok done for tonight but I will jot down what I think is wrong here. OptimizeDelegationPass is not examining the usage of block variables at all in children scopes. This is a little more involved than uncommenting out @subbuss FIXME processing of the children scopes, but we need to consider any ordinary usage of blocks in children scopes. |
This replaces the previous fix. The previous fix was wrong because the code in question contained a closure and we were not marking the parent method as scope as BINDING_HAS_ESCAPED. As a result, OptimizeDelegationPass was executing and mucking things up. The previous fix corrected the pass to work with nested closures but it would create new problems if that closure did something which needed to conume the parents binding. The new fix is just a simple oversight in a few of our instructions. ZSuper, UnresolvesSuper, and Match are calls but they were not calling their superclasses computeScopeFlags. This is turn made the issue at hand not notice that the method contained a closure so it never marked BINDING_HAS_ESCAPED. This fix should potentially fix other weird errors where we did not set common call IRScope flags.
Running Sequel's integration tests with 9.0.0.0 rc1 brings up an error similar to the following for most adapters:
This seems to be related to instance evaled blocks and super usage in the constraint_validations plugin, but I was unable to reduce it to a smaller example. The specs pass correctly on pre1, similar failure on pre2.
The text was updated successfully, but these errors were encountered: