Bug 114596 – Do not generate parameter names in WebKitIDL C++ bindings

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebCore Misc.

[Victor Costan]

Currently, the C++ WebKitIDL code generator adds parameter names to the function declarations in headers. This upsets the WebKit style checker, so WebKitIDL changes that re-generate the bindings (as they should) automatically fail the style checks.

This bug will receive a patch that removes the parameter names, to make life easier for future WebKitIDL changes.

[Victor Costan]

Created attachment 198013 [details]
Patch

[Victor Costan]

Sorry, my initial description is incorrect. Only the test cases for the WebKitIDL code generator are checked in, which means only patches that change the generators, like [20141], will get flagged by the style checker.

Nevertheless, it would be nice to not have this problem.

[20141] https://bugs.webkit.org/show_bug.cgi?id=20141

[Brent Fulgham]

Comment on attachment 198013 [details]
Patch

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

I like the intent behind this change, but I'm wondering if we might need something more sophisticated.  When we have multiple arguments of the same type, it seems like we SHOULD have an argument name to document what the different parameters are meant to do.

Although the current labels are not all that helpful, some of them could be changed to be more descriptive.

If the IDL does not provide an argument name, will the generator produce the desired output?  Maybe fixing/adjusting the IDL would be a good thing to do instead/in addition?

> Source/WebCore/bindings/scripts/test/CPP/WebDOMTestSerializedScriptValueInterface.h:-56
> -    void multiTransferList(const WebDOMString& first, const WebDOMArray& tx, const WebDOMString& second, const WebDOMArray& txx);

Is it really improper to have some context for these arguments?  How do we know what the first and second WebDOMStrings are supposed to represent?

Maybe it's not always improper to have a label (although these labels are not very helpful!)

[Andreas Kling]

The C++ bindings have been removed.