Bug 253810 – [WPE] Webkit API object/struct names hidden from Swift import after change to 2022 API

• Status: RESOLVED
• Resolution: INVALID
• Component: WPE WebKit

[Ryan Walklin]

I have a number of client applications using WPE WebKit and a Wayland renderer with Swift 5.7 on Linux, and have just built 2.39.91 and found that the new GLib API has changed the visibility of a number of struct which is preventing their import by name in Swift.

For example, the below code to bring up a Web Extension works with 2.39.5 (which is neat), but fails to compile with 2.39.91:


fileprivate var pageCreatedCallback: @convention(c) (OpaquePointer, OpaquePointer, OpaquePointer) -> Void = { (extension, page, data) in
    print("Page created")
}

@_cdecl("webkit_web_process_extension_initialize_with_user_data")
func initialize (extension: UnsafeMutablePointer<WebKitWebProcessExtension>, data: OpaquePointer?) {
    g_signal_connect_data(`extension`, "page-created", unsafeBitCast(pageCreatedCallback, to: GCallback.self), nil, nil, GConnectFlags(rawValue: 0))
}

The error is:

error: cannot find type 'WebKitWebProcessExtension' in scope
func initialize (extension: UnsafePointer<WebKitWebProcessExtension>, data: OpaquePointer?) {
                                          ^~~~~~~~~~~~~~~~~~~~~~~~~

If I change the declaration to OpaquePointer, then the example compiles, but I lose type information. This is replicated across the entire API, and appears to be the result of using WEBKIT_DECLARE_FINAL_TYPE for the 2022 API rather than the previous typedef method: 

typedef struct _WebKitWebExtension        WebKitWebExtension;

This may be something that can be worked around, but I note the new macro is a customisation of G_DECLARE_FINAL_TYPE, is there any way this can be improved so the symbols are available to Swift?

[Michael Catanzaro]

Are these g-ir bindings? I didn't know that support for Swift existed. I guess something is wrong with the Swift bindings or your use of them, because these are public types. WEBKIT_DECLARE_FINAL_TYPE itself declares the typedefs, and there's no way that g-ir would ever look at typedefs anyway.

First, please confirm that you've adjusted the API version that you're using because, like the type names, it changed from wpe-web-extension to wpe-web-process-extension. If you've got that right, then I recommend reporting a bug to the bindings that you are using.

(P.S. We're done making API changes now, so once you manage to make this jump, there will be no more surprises....)

[Michael Catanzaro]

If the bindings are maintained manually, could it be they've just not been updated yet?

[Ryan Walklin]

Thanks for the replies. No no bindings as such, it is sufficient to just create a Clang module and umbrella header for each library, and then the C API can be called directly, so I just have a wayland-client one, as well as wpe-webkit itself and the GL libraries required, which is enough to render to a wayland surface and manage input, much the same way as Cog does.

I did note the API change, and agree that the change in the way the headers are generated should still mean the types can be imported as opaque named structs. 

I presume I am doing something wrong, but as noted it did work well with 2.39.5, so I will keep working on it. If I can get Clang to output a preprocessed header for the WPE library than that will hopefully let me see what has changed.

[Michael Catanzaro]

It sounds very likely that there is some bug in your custom stuff that we do not know about. ;)

[Ryan Walklin]

Hi all, thanks for the comments, as you had suspected this is actually due to the way Swift imports any C opaque struct as an OpaquePointer type, whereas I was previously able to use an UnsafeMutablePointer<Type>. 

Annoying that this is how incomplete structs are imported, but using typealias in Swift allows most of the type info to be retained, and after updating my use of the library the 2022 API works well called directly from Swift 5.8. Closing as NOTABUG,