Bug 149923

Summary: Rationalize JSXXConstructor class definition generated from WebIDL
Product: WebKit Reporter: youenn fablet <youennf>
Component: WebCore JavaScriptAssignee: youenn fablet <youennf>
Status: RESOLVED FIXED    
Severity: Normal CC: cdumez, commit-queue, darin, ossy
Priority: P2    
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 149956    
Bug Blocks:    
Attachments:
Description Flags
Patch
none
Patch for landing none

Description youenn fablet 2015-10-08 05:42:19 PDT
Depending on the WebIDL and options, the JSXXConstructor generated class declaration is changing.
It may be useful to rationalize this so that it can be later templated, which would simplify the binding generator work.
Comment 1 youenn fablet 2015-10-08 07:16:46 PDT
Created attachment 262693 [details]
Patch
Comment 2 youenn fablet 2015-10-08 08:13:49 PDT
(In reply to comment #1)
> Created attachment 262693 [details]
> Patch

mac-wk2 compilation is failing for an unrelated reason, see bug 149751.
Comment 3 Darin Adler 2015-10-08 08:38:49 PDT
Comment on attachment 262693 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=262693&action=review

> Source/WebCore/bindings/scripts/CodeGeneratorJS.pm:4836
> +                my $overloadedIndexString .= $function->{overloadedIndex};

I don’t understand the use of ".=" instead of "=" here.

> Source/WebCore/bindings/scripts/CodeGeneratorJS.pm:5021
> +                push(@$outputArray, "#endif // $conditionalString\n");

I don’t think comments like this one are useful when the entire body of #if/#else/#endif is only 6 lines long. Especially in generated code that people should typically not be reading.
Comment 4 youenn fablet 2015-10-08 08:57:40 PDT
(In reply to comment #3)
> Comment on attachment 262693 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=262693&action=review
> 
> > Source/WebCore/bindings/scripts/CodeGeneratorJS.pm:4836
> > +                my $overloadedIndexString .= $function->{overloadedIndex};
> 
> I don’t understand the use of ".=" instead of "=" here.

Right.
Let's also remove $overloadedIndexString at the same time.

> 
> > Source/WebCore/bindings/scripts/CodeGeneratorJS.pm:5021
> > +                push(@$outputArray, "#endif // $conditionalString\n");
> 
> I don’t think comments like this one are useful when the entire body of
> #if/#else/#endif is only 6 lines long. Especially in generated code that
> people should typically not be reading.

OK
Comment 5 youenn fablet 2015-10-09 05:59:44 PDT
Created attachment 262764 [details]
Patch for landing
Comment 6 WebKit Commit Bot 2015-10-09 06:45:15 PDT
Comment on attachment 262764 [details]
Patch for landing

Clearing flags on attachment: 262764

Committed r190785: <http://trac.webkit.org/changeset/190785>
Comment 7 WebKit Commit Bot 2015-10-09 06:45:20 PDT
All reviewed patches have been landed.  Closing bug.
Comment 8 Csaba Osztrogonác 2015-10-09 08:45:29 PDT
Comment on attachment 262764 [details]
Patch for landing

View in context: https://bugs.webkit.org/attachment.cgi?id=262764&action=review

> Source/WebCore/bindings/scripts/CodeGeneratorJS.pm:5020
> -            push(@$outputArray, "#if $conditionalString\n") if $conditionalString;
>              push(@$outputArray, "ConstructType ${constructorClassName}::getConstructData(JSCell*, ConstructData& constructData)\n");
>              push(@$outputArray, "{\n");
> -            push(@$outputArray, "    constructData.native.function = construct${className};\n");
> -            push(@$outputArray, "    return ConstructTypeHost;\n");
> +            if ($conditionalString) {
> +                push(@$outputArray, "#if $conditionalString\n");
> +                push(@$outputArray, "    constructData.native.function = construct;\n");
> +                push(@$outputArray, "    return ConstructTypeHost;\n");
> +                push(@$outputArray, "#else\n");
> +                push(@$outputArray, "    return Base::getConstructData(cell, constructData);\n");
> +                push(@$outputArray, "#endif\n");

The #else case causes build failure, because there is no cell named variable/argument here.
Comment 9 Csaba Osztrogonác 2015-10-09 08:47:10 PDT
I'm going to fix this in bug149956.