WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
70101
Implement [Constructor] IDL for JSC
https://bugs.webkit.org/show_bug.cgi?id=70101
Summary
Implement [Constructor] IDL for JSC
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
Details
Formatted Diff
Diff
Patch
(82.34 KB, patch)
2011-10-15 23:40 PDT
,
Kentaro Hara
no flags
Details
Formatted Diff
Diff
Patch
(70.51 KB, patch)
2011-10-16 04:43 PDT
,
Kentaro Hara
no flags
Details
Formatted Diff
Diff
Rebased patch for review
(71.41 KB, patch)
2011-10-16 07:03 PDT
,
Kentaro Hara
no flags
Details
Formatted Diff
Diff
Show Obsolete
(3)
View All
Add attachment
proposed patch, testcase, etc.
Kentaro Hara
Comment 1
2011-10-14 07:03:28 PDT
Created
attachment 111010
[details]
Patch
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
Created
attachment 111177
[details]
Patch
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
Created
attachment 111179
[details]
Patch
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.
Top of Page
Format For Printing
XML
Clone This Bug