Like [StrictTypeChecking, Custom] void getParameter(); instead of any getParameter(in GLenum pname) raises(DOMException);
Created attachment 189240 [details] Patch
Created attachment 189243 [details] Diff of generators changes
Comment on attachment 189240 [details] Patch Given that these methods are [Custom], signature changes in IDL files won't affect generated code. I wonder why there is diff in generated code for ObjC. I thought that [Custom] methods are skipped in ObjC.
(In reply to comment #3) > (From update of attachment 189240 [details]) > I wonder why there is diff in generated code for ObjC. I thought that [Custom] methods are skipped in ObjC. Ah, I remembered. CodeGeneratorObjC.pm doesn't support [Custom] attributes/methods, but it doesn't skip [Custom] attributes/methods for some reason. If we try to skip them, ObjC bindings break because of a bunch of special handling in CodeGeneratorObjC.pm. Either way, this change won't break ObjC bindings. LGTM.
(In reply to comment #3) > (From update of attachment 189240 [details]) > Given that these methods are [Custom], signature changes in IDL files won't affect generated code. > > I wonder why there is diff in generated code for ObjC. I thought that [Custom] methods are skipped in ObjC. The tmp/bindings/DOMWebGLRenderingContext.h file already uses a suspicious DOMany* (line 417). I wonder if this generated code for ObjC is usable at all.
(In reply to comment #5) > The tmp/bindings/DOMWebGLRenderingContext.h file already uses a suspicious DOMany* (line 417). I wonder if this generated code for ObjC is usable at all. Yes, it is completely unusable. But we cannot simply stop generating the code because stopping the generation affects other parts of ObjC bindings and breaks them:)
ObjC bindings -> cry
Comment on attachment 189240 [details] Patch Clearing flags on attachment: 189240 Committed r143432: <http://trac.webkit.org/changeset/143432>
All reviewed patches have been landed. Closing bug.