java.lang.IncompatibleClassChangeError in 9.0.0.0 rc1 #3056
Labels
Milestone
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. |
enebo
added a commit
that referenced
this issue
Jun 30, 2015
enebo
added a commit
that referenced
this issue
Jun 30, 2015
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: