Support for latest WebIDL for indexed property getters.

Support for latest WebIDL for indexed property getters.

Currently Blink WebIDL is old and defined indexed property getter
as [IndexedGetter], which has a problem that sometimes
we can't get return type and method name via IDL.

Now
getter type identifier(unsigned long identifier);
means the function is used as indexed property getter,
as described in:
http://www.w3.org/TR/WebIDL/#idl-indexed-properties

At the same time, generator now generate toV8Fast instead of toV8
for all indexed getter because wrappable is known in those cases.

R=haraken@chromium.org
BUG=229740
TEST=TestEventTarget

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=149564

[kojih, 2013-05-01 04:36:29]

r?

https://codereview.chromium.org/14751005/diff/1/Source/bindings/scripts/CodeG...
File Source/bindings/scripts/CodeGeneratorV8.pm (left):

https://codereview.chromium.org/14751005/diff/1/Source/bindings/scripts/CodeG...
Source/bindings/scripts/CodeGeneratorV8.pm:3028: $indexerType =
"WebKitCSSKeyframeRule";
These special patterns are now treated by MakeDummyFunction.

https://codereview.chromium.org/14751005/diff/1/Source/bindings/scripts/CodeG...
File Source/bindings/scripts/CodeGeneratorV8.pm (right):

https://codereview.chromium.org/14751005/diff/1/Source/bindings/scripts/CodeG...
Source/bindings/scripts/CodeGeneratorV8.pm:460: }
I aggregated WebKitCSSKeyframesRule related many special cases to here.
I think usnig MakeDummyFunction is smarter to live with this pattern.

[haraken, 2013-05-01 06:22:11]

The patch looks correct but I'm not 100% sure because the patch changes a bunch
of if conditions. Would you double-check that there is no change in generated
code?

https://codereview.chromium.org/14751005/diff/1/Source/bindings/scripts/CodeG...
File Source/bindings/scripts/CodeGeneratorV8.pm (right):

https://codereview.chromium.org/14751005/diff/1/Source/bindings/scripts/CodeG...
Source/bindings/scripts/CodeGeneratorV8.pm:460: }

Actually I don't want to change the parse tree structure in the code generator.
In the first place, this special case should be removed in the near future. How
much will it mess up the code if you don't introduce MakeDummyFunction()?

[kojih, 2013-05-01 08:50:21]

sorry I found 1 difference(enumerator of WebKitCSSKeyframesRule) in generated
code.

There's exactly only changes toV8->toV8Fast in generated code in Patch set 2.

https://codereview.chromium.org/14751005/diff/1/Source/bindings/scripts/CodeG...
File Source/bindings/scripts/CodeGeneratorV8.pm (right):

https://codereview.chromium.org/14751005/diff/1/Source/bindings/scripts/CodeG...
Source/bindings/scripts/CodeGeneratorV8.pm:460: }
Without MakeDummyFunction(), I have to add special case such as
$interfaceName eq "WebKitCSSKeyframesRule" || ...
to the code:

GenerateHeaderNamedAndIndexedPropertyAccessors:
 - my $hasIndexedGetter = GetIndexedGetterFunction($interface) ||
$interface->extendedAttributes->{"CustomIndexedGetter"};
   because generator have to generate indexed getter prototype without IDL
function
GenerateImplementationIndexedProperty:
 - if (!$indexedGetterfunction && !$hasCustomIndexedGetter) {
   because generator have to generate indexed getter implementation without IDL
function
 - NativeToJSValue($indexedGetterfunction->signature)
   as NativeToJSValue calls signature->type which can not be prepared in case of
WebKitCSSKeyframesRule
 - my $returnType = $indexedGetterfunction->signature->type;
   ditto.
 - my $methodName = $indexedGetterfunction->signature->name;
   ditto.

MakeDummyFunction() does not change existing $interface.
it just generate dummy structure for later code to use.
Altough Both is not clean, I think MakeDummyFunction() is better way.

https://codereview.chromium.org/14751005/diff/4001/Source/bindings/scripts/Co...
File Source/bindings/scripts/CodeGeneratorV8.pm (right):

https://codereview.chromium.org/14751005/diff/4001/Source/bindings/scripts/Co...
Source/bindings/scripts/CodeGeneratorV8.pm:3042: }
Although I think every object that have IndexedPropertyGetter should also have
IndexedPropertyEnumerator,
This is necessary so that generated codes are exactly same as before.
(Current WebKitCSSKeyframesRule does not have IndexedPropertyEnumerator)

"enumerator 	The callback to invoke to enumerate all the indexed properties of
an object.":
http://bespin.cz/~ondras/html/classv8_1_1ObjectTemplate.html#af436aeb8132068d...

[haraken, 2013-05-01 18:07:25]

Thanks for the update. The change from toV8() to toV8Fast() is OK (rather,
fine!). LGTM.

Let's fix the hack for WebKitCSSKeyframesRule asap:)

[commit-bot: I haz the power, 2013-05-02 01:22:45]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/kojih@chromium.org/14751005/4001

[commit-bot: I haz the power, 2013-05-02 02:20:15]

Change committed as 149564