Update Objective-C code generator to pass a reference to calling object for partial interfaces

[Nikos Andronikos]

This patch fixes errors caused by bug 151682, which changed the code for JS bindings to pass a reference to the object when calling static member functions.

The error is in the generated Objective-C code for partial interfaces:

   webkit/WebKitBuild/Debug/DerivedSources/WebCore/DOMDocument.mm:443:65: error: non-const lvalue reference to type 'WebCore::Document' cannot bind to a temporary of type 'WebCore::Document *'
       return kit(WTF::getPtr(WebCore::DocumentAnimation::timeline(IMPL)));
                                                                   ^~~~
   webkit/WebKitBuild/Debug/DerivedSources/WebCore/DOMDocument.mm:106:14: note: expanded from macro 'IMPL'
   #define IMPL static_cast<WebCore::Document*>(reinterpret_cast<WebCore::Node*>(_internal))

The fix updates Objective-C code generator to pass a reference to calling object for partial interfaces.

[Nikos Andronikos]

Created attachment 266427 [details]
Patch

[Darin Adler]

Comment on attachment 266427 [details]
Patch

This seems sort of pointless. I don’t think we’ll be generating Objective-C bindings for partial interfaces. We have different ideas about how to expose DOM to Objective-C and Swift. It’s OK to fix the code generator, but we never plan to use it!

[WebKit Commit Bot]

Comment on attachment 266427 [details]
Patch

Clearing flags on attachment: 266427

Committed r193637: <http://trac.webkit.org/changeset/193637>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[youenn fablet]

Should ObjC generator skips generating code for ImplementedBy functions and attributes then?

[Darin Adler]

(In reply to comment #5)
> Should ObjC generator skips generating code for ImplementedBy functions and
> attributes then?

I’m not 100% sure we can do exactly that, but we could start doing something along those lines. Generally speaking what we probably want is to keep the existing Objective-C bindings working but not add more to them.

Note that there was no problem compiling WebKit even without this bug fix. I don’t know of any actual binding that we compile with Objective-C that was affected by this fix.

There are many new DOM APIs where we don’t have a good mapping to Objective-C in the bindings, but it doesn’t matter if we do not try to expose those new DOM APIs.

[Nikos Andronikos]

(In reply to comment #6)
> (In reply to comment #5)
> > Should ObjC generator skips generating code for ImplementedBy functions and
> > attributes then?
> 
> I’m not 100% sure we can do exactly that, but we could start doing something
> along those lines. Generally speaking what we probably want is to keep the
> existing Objective-C bindings working but not add more to them.
> 
> Note that there was no problem compiling WebKit even without this bug fix. I
> don’t know of any actual binding that we compile with Objective-C that was
> affected by this fix.

The affected code is in the new Web Animations impl - see bug 151688 
Web Animations defines an extension to the Document interface.
http://w3c.github.io/web-animations/#extensions-to-the-document-interface

> 
> There are many new DOM APIs where we don’t have a good mapping to
> Objective-C in the bindings, but it doesn’t matter if we do not try to
> expose those new DOM APIs.

So what's the mechanism for not exposing those APIs to Objective-C?

[Darin Adler]

(In reply to comment #7)
> So what's the mechanism for not exposing those APIs to Objective-C?

We have multiple mechanisms, none really elegant, and could add more. One approach is to use one of these in IDL files:

#if !defined(LANGUAGE_OBJECTIVE_C) || !LANGUAGE_OBJECTIVE_C
#if defined(LANGUAGE_JAVASCRIPT) && LANGUAGE_JAVASCRIPT

Another approach is that CodeGeneratorObjC.pm will omit certain thing entirely based on attributes or other aspects of the IDL. For example, I removed support for nullables entirely recently, so they are just ignored, similarly [Private] functions are ignored, [CustomBinding] items are ignored, [EventHandler] items are ignored.

Another approach is to list filenames to skip in this DerivedSources.make line:

OBJC_DOM_HEADERS=$(filter-out DOMDOMWindow.h DOMDOMMimeType.h DOMDOMPlugin.h,$(OBJC_DOM_CLASSES:%=DOM%.h))

Two more peculiar things about Objective-C DOM:

1) only things listed in bindings/objc/PublicDOMInterfaces.h get to be API; others are considered non-public SPI on OS X
2) the Objective-C DOM doesn't exist at all on iOS

[Nikos Andronikos]

(In reply to comment #8)
> (In reply to comment #7)
> > So what's the mechanism for not exposing those APIs to Objective-C?
> 
> We have multiple mechanisms, none really elegant, and could add more. One
> approach is to use one of these in IDL files:
> 
> #if !defined(LANGUAGE_OBJECTIVE_C) || !LANGUAGE_OBJECTIVE_C
> #if defined(LANGUAGE_JAVASCRIPT) && LANGUAGE_JAVASCRIPT

For now, we've chosen to adopt this method and won't expose the web animations API to Objective-C. 
See bug 151688.