Bug 70101

Summary: Implement [Constructor] IDL for JSC
Product: WebKit Reporter: Kentaro Hara <haraken>
Component: DOMAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: abarth, ap, dominicc, donggwan.kim, sam, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 65839    
Attachments:
Description Flags
Patch
none
Patch
none
Patch
none
Rebased patch for review none

Kentaro Hara
Reported 2011-10-14 05:17:48 PDT
Currently, all constructors of JSC are manually written as custom constructors in WebCore/bindings/js/*.cpp. We need to support [Constructor] IDL in JSC. After this patch is landed, I am planning to replace 6 custom constructors in JSC with the [Constructor] IDL. Please see the bug 65839 for more details. The spec of [Constructor] IDL: http://www.w3.org/TR/WebIDL/#Constructor Implement [Constructor] IDL for V8: bug 66536
Attachments
Patch (82.48 KB, patch)
2011-10-14 07:03 PDT, Kentaro Hara
no flags
Patch (82.34 KB, patch)
2011-10-15 23:40 PDT, Kentaro Hara
no flags
Patch (70.51 KB, patch)
2011-10-16 04:43 PDT, Kentaro Hara
no flags
Rebased patch for review (71.41 KB, patch)
2011-10-16 07:03 PDT, Kentaro Hara
no flags
Kentaro Hara
Comment 1 2011-10-14 07:03:28 PDT
Adam Barth
Comment 2 2011-10-14 11:21:56 PDT
Comment on attachment 111010 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=111010&action=review > Source/WebCore/bindings/scripts/CodeGeneratorJS.pm:3266 > + # We do not also support a constructor [Opitional] argument without CallWithDefaultValue. Opitional <-- typo > Source/WebCore/bindings/scripts/test/JS/JSTestInterface.cpp:111 > + ScriptExecutionContext* scriptContext = static_cast<JSDOMGlobalObject*>(exec->lexicalGlobalObject())->scriptExecutionContext(); > + if (!scriptContext) > + return JSValue::encode(jsUndefined()); Why is this variable check needed? It's not used in this function. > Source/WebCore/bindings/scripts/test/JS/JSTestInterface.cpp:122 > + RefPtr<TestInterface> object = TestInterface::create(str1, str2, context, ec); This seems to be passing context at the end instead of the beginning. > Source/WebCore/bindings/scripts/test/JS/JSTestInterface.h:91 > +class JSTestInterfaceConstructor : public DOMConstructorObject { I don't quite understand when this moved from the cpp file to the h file.
Kentaro Hara
Comment 3 2011-10-15 23:40:15 PDT
Kentaro Hara
Comment 4 2011-10-15 23:43:17 PDT
(In reply to comment #2) > (From update of attachment 111010 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=111010&action=review > > > Source/WebCore/bindings/scripts/CodeGeneratorJS.pm:3266 > > + # We do not also support a constructor [Opitional] argument without CallWithDefaultValue. > > Opitional <-- typo Fixed. > > Source/WebCore/bindings/scripts/test/JS/JSTestInterface.cpp:111 > > + ScriptExecutionContext* scriptContext = static_cast<JSDOMGlobalObject*>(exec->lexicalGlobalObject())->scriptExecutionContext(); > > + if (!scriptContext) > > + return JSValue::encode(jsUndefined()); > > Why is this variable check needed? It's not used in this function. Removed this check. > > Source/WebCore/bindings/scripts/test/JS/JSTestInterface.cpp:122 > > + RefPtr<TestInterface> object = TestInterface::create(str1, str2, context, ec); > > This seems to be passing context at the end instead of the beginning. Sorry, fixed.
Kentaro Hara
Comment 5 2011-10-16 04:43:31 PDT
Kentaro Hara
Comment 6 2011-10-16 04:44:19 PDT
Comment on attachment 111010 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=111010&action=review >> Source/WebCore/bindings/scripts/test/JS/JSTestInterface.h:91 >> +class JSTestInterfaceConstructor : public DOMConstructorObject { > > I don't quite understand when this moved from the cpp file to the h file. Currently, the declaration of XXXXConstructor exists on the h file if the constructor is a custom constructor, and on the cpp file if the constructor is not a custom constructor. This is inconsistent and I think that all declarations should exist on the h file. Practical problem: For example, JSDOMWindowCustom.cpp assumes that the declaration of EventSourceConstructor exists on the h file. Currently, JSDOMWindowCustom.cpp can be compiled, since EventSourceConstructor is written as a custom constructor and thus it is declared on the h file. However, in a coming patch, I am planning to generate EventSourceConstructor by [Constructor] IDL, which will put the declaration to the cpp file (unless we move the declaration from the cpp file to the h file by this patch). This makes JSDOMWindowCustom.cpp fail to compile.
Kentaro Hara
Comment 7 2011-10-16 07:03:56 PDT
Created attachment 111180 [details] Rebased patch for review
Adam Barth
Comment 8 2011-10-16 12:56:28 PDT
Comment on attachment 111180 [details] Rebased patch for review ok!
WebKit Review Bot
Comment 9 2011-10-16 16:29:15 PDT
Comment on attachment 111180 [details] Rebased patch for review Clearing flags on attachment: 111180 Committed r97578: <http://trac.webkit.org/changeset/97578>
WebKit Review Bot
Comment 10 2011-10-16 16:29:20 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.