RESOLVED FIXED 89070
[JSC/V8] Improve DOMString[] support
https://bugs.webkit.org/show_bug.cgi?id=89070
Summary [JSC/V8] Improve DOMString[] support
Kent Tamura
Reported 2012-06-14 00:54:06 PDT
If we use DOMString[] for - an argument of a non-overload function - an return value of a function, our binding generators produce wrong code.
Attachments
Patch (12.34 KB, patch)
2012-06-14 01:01 PDT, Kent Tamura
no flags
Patch 2 (12.30 KB, patch)
2012-06-14 01:04 PDT, Kent Tamura
no flags
Patch for landing (12.30 KB, patch)
2012-06-14 01:46 PDT, Kent Tamura
no flags
Kent Tamura
Comment 1 2012-06-14 01:01:22 PDT
Kent Tamura
Comment 2 2012-06-14 01:04:42 PDT
Created attachment 147512 [details] Patch 2 Remove useless comment
Adam Barth
Comment 3 2012-06-14 01:05:36 PDT
Looks reasonable, but I'd like haraken to take a look.
Kentaro Hara
Comment 4 2012-06-14 01:09:47 PDT
Comment on attachment 147512 [details] Patch 2 View in context: https://bugs.webkit.org/attachment.cgi?id=147512&action=review Looks reasonable to me too. > Source/WebCore/bindings/js/JSDOMBinding.cpp:153 > + if (!stringList) > + return jsUndefined(); Just a confirmation: You are intending to return (not [] but) undefined for a null stringList, right?
Vineet Chaudhary (vineetc)
Comment 5 2012-06-14 01:13:25 PDT
Comment on attachment 147512 [details] Patch 2 View in context: https://bugs.webkit.org/attachment.cgi?id=147512&action=review > Source/WebCore/bindings/scripts/CodeGeneratorJS.pm:-3075 > - if (!$codeGenerator->SkipIncludeHeader($arrayType)) { tkent: can we add "DOMString[]" to SkipIncludeHeader() ..? because I think this will fail for numerictypes like float[]. I mean will include float.h to cpp files.
Kent Tamura
Comment 6 2012-06-14 01:18:51 PDT
Comment on attachment 147512 [details] Patch 2 View in context: https://bugs.webkit.org/attachment.cgi?id=147512&action=review >> Source/WebCore/bindings/js/JSDOMBinding.cpp:153 >> + return jsUndefined(); > > Just a confirmation: You are intending to return (not [] but) undefined for a null stringList, right? Oh, this should be null to match V8 binding behavior. I'll change it so. Thanks.
Kent Tamura
Comment 7 2012-06-14 01:20:38 PDT
Comment on attachment 147512 [details] Patch 2 View in context: https://bugs.webkit.org/attachment.cgi?id=147512&action=review >> Source/WebCore/bindings/scripts/CodeGeneratorJS.pm:-3075 >> - if (!$codeGenerator->SkipIncludeHeader($arrayType)) { > > tkent: can we add "DOMString[]" to SkipIncludeHeader() ..? because I think this will fail for numerictypes like float[]. I mean will include float.h to cpp files. ok, will do.
Vineet Chaudhary (vineetc)
Comment 8 2012-06-14 01:28:50 PDT
(In reply to comment #7) > (From update of attachment 147512 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=147512&action=review > > >> Source/WebCore/bindings/scripts/CodeGeneratorJS.pm:-3075 > >> - if (!$codeGenerator->SkipIncludeHeader($arrayType)) { > > > > tkent: can we add "DOMString[]" to SkipIncludeHeader() ..? because I think this will fail for numerictypes like float[]. I mean will include float.h to cpp files. > > ok, will do. Ahh sorry tkent previous comment you are handling that in elsif.
Kent Tamura
Comment 9 2012-06-14 01:35:38 PDT
Comment on attachment 147512 [details] Patch 2 View in context: https://bugs.webkit.org/attachment.cgi?id=147512&action=review >>>> Source/WebCore/bindings/scripts/CodeGeneratorJS.pm:-3075 >>>> - if (!$codeGenerator->SkipIncludeHeader($arrayType)) { >>> >>> tkent: can we add "DOMString[]" to SkipIncludeHeader() ..? because I think this will fail for numerictypes like float[]. I mean will include float.h to cpp files. >> >> ok, will do. > > Ahh sorry tkent previous comment you are handling that in elsif. ok, no problem. Anyway, we might not need to include JSDOMStringList.h and DOMStringList.h.
Kent Tamura
Comment 10 2012-06-14 01:44:11 PDT
(In reply to comment #9) > Anyway, we might not need to include JSDOMStringList.h and DOMStringList.h. I'll investigate this later.
Kent Tamura
Comment 11 2012-06-14 01:46:06 PDT
Created attachment 147517 [details] Patch for landing undefined -> null
Kent Tamura
Comment 12 2012-06-14 02:59:35 PDT
Kent Tamura
Comment 13 2012-06-14 17:50:41 PDT
(In reply to comment #6) > (From update of attachment 147512 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=147512&action=review > > >> Source/WebCore/bindings/js/JSDOMBinding.cpp:153 > >> + return jsUndefined(); > > > > Just a confirmation: You are intending to return (not [] but) undefined for a null stringList, right? > > Oh, this should be null to match V8 binding behavior. I'll change it so. I was incorrect. We doesn't have V8 binding code to convert a DOMStringList to v8 array. I looked a wrong code. Probably we should have different behavior for "DOMString[]" and "DOMString[]?".
Kentaro Hara
Comment 14 2012-06-14 17:52:23 PDT
(In reply to comment #13) > I was incorrect. We doesn't have V8 binding code to convert a DOMStringList to v8 array. I looked a wrong code. > Probably we should have different behavior for "DOMString[]" and "DOMString[]?". Yes. DOMString[] is not nullable, but DOMString[]? is nullable: http://www.w3.org/TR/WebIDL/#idl-nullable-type
Kent Tamura
Comment 15 2012-06-14 18:27:33 PDT
Ok, code generators should produce v8ArrayOrNull() / jsArrayOrNull() for "DOMString[]?". So, jsArray() / v8Array() should not return null/undefined. I'll make a patch.
Note You need to log in before you can comment on or make changes to this bug.