[Webkit-unassigned] [Bug 26398] Move IDL extended attributes to the location specified in WebIDL

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=26398





--- Comment #57 from Kentaro Hara <haraken at chromium.org>  2012-09-19 23:20:11 PST ---
Thanks for all the clarification.

> >> Source/WebCore/bindings/scripts/test/TestObj.idl:232
> >> +        void convert5(in [TreatNullAs=NullString, TreatUndefinedAs=NullString] e value);
> > 
> > 'a', 'b', 'd', 'e' are not valid type names. Shall we change them to DOMString or something?
> 
> I think, 'a', 'b', 'd', 'e' are for checking the case where some user-defined class is specified. WebIDL allows users to use any identifier as NonAnyType.

OK. Then let's change them to 'UserDefinedType' or something like that. You can do it in a follow-up patch.


> >> Source/WebCore/bindings/scripts/test/V8/V8TestObj.cpp:168
> >> +    return v8Integer(imp->longAttr(), info.GetIsolate());
> > 
> > I know that this code is conformed to the spec. But isn't there any compatibility concern to change a double to an integer?
> 
> This double is a bug of old IDLParser.pm. TestObj.idl has "attribute long longAttr;". The old IDLParser.pm cannot parse the line correctly. So the parser generates the code for "long long" + "Attr". But the correct result should be "long" + "longAttr".
> 
> >> Source/WebCore/bindings/scripts/test/V8/V8TestObj.cpp:454
> >> +    imp->setAttrWithGetterException(v);
> > 
> > Where does this change come from? Is it correct?
> 
> The code is generated from "attribute long attrWithGetterException getter raises(DOMException);". So 2 methods are generated, one is attrWithGetterExceptionAttrGetter and the other is attrWithGetterExceptionAttrSetter.
> Since only "getter raises" is specified, "setter" should not raise any exception. Does this make sense?

Makes sense.

I'd like to confirm one thing: There are changes in the generated code for bindings/scripts/tests/*.idl, but there is no meaningful change in the generated code for real idl files for JSC/V8/ObjC/GObject/CPP, right?

If it is right, I'm happy to r+ the patch.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.