gwt /
gwt /
22a4f8320b721fdd4c228d00ab51c5309729afa2 Fix for issue #319. Reviewed by gwt.team.mmendez
http://code.google.com/p/google-web-toolkit/issues/detail?id=319
The problem is that calling super.foo() fails to dispatch statically if
super.foo() happens to be a native method. The generated code actually
performs a polymorphic call, which incorrectly does dynamic dispatch to
the most derived subclass implementation.
Why does this only happen with a native super.foo()?
Well, it's kind of tricky. :) If super.foo() is non-native, we will
create a static impl method, super.$foo() and call that one statically
from the super.foo() call site. In fact, we have been depending on this
ability to correctly dispatch super calls in general. The problem is, we
specifically cannot staticify native methods right now. So the call site
remains bound to the instance version, and during code gen creates a
polymorphic call, even though the correct field is set on the JMethodCall
to not do dynamic dispatch.
My fix is this: if we find during code gen that we must statically
dispatch an instance method, we now generate a "call" syntax construct in
the output. For example:
Old, bad code:
function Hello$onModuleLoad(this$static) {
this$static.onModuleLoad__(); // wrong
}
New, good code:
function Hello_$onModuleLoad(this$static) {
Foo_onModuleLoad.call(this$static);
}
As part of this fix, I refactored JMethodCall's concept of
"canBePolymorphic", which was ambiguous between the instance variable
(and setter) and the getter. Instead, the variable, getter, and setter
are now "staticDispatchOnly", and "canBePolymorphic" is a computed result.
git-svn-id: https://google-web-toolkit.googlecode.com/svn/trunk@221 8db76d5a-ed1c-0410-87a9-c151d255dfc7
6 files changed
