Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 9108058d4e9513a5acd31d0491af9ced6a7800a7
      
https://github.com/WebKit/WebKit/commit/9108058d4e9513a5acd31d0491af9ced6a7800a7
  Author: Adrian Taylor <[email protected]>
  Date:   2025-11-19 (Wed, 19 Nov 2025)

  Changed paths:
    M Source/WebKit/Configurations/WebKit.xcconfig
    M Source/WebKit/UIProcess/API/Swift/WebPage.swift
    M Source/WebKit/UIProcess/WebPageProxy.cpp
    M Source/WebKit/WebKit.xcodeproj/project.pbxproj

  Log Message:
  -----------
  Switch to build-in Swift/C++ interop header generation
https://bugs.webkit.org/show_bug.cgi?id=298398
rdar://159856155

Reviewed by Richard Robinson.

This reverts to using a single Swift/[objective-]C[++] interop header,
on modern SDKs.

Currently the only Swift feature in the WebKit target is the Swift demo feature
which is enabled using ENABLE_BACKFORWARDLIST_SWIFT. This tests bidirectional
Swift <-> C++ interoperability; calls in the C++ to Swift direction rely on 
Swift
generating a header file containing declarations of all the relevant Swift data
types and functions, such that they can be used from C++.

Until now, we've generated that header file using a custom Xcode build step and
script. This has some key limitations, notably that it isn't aware of all the
C++ preprocessor definitions nor include paths. Thus, if the Swift itself
referred to any significant parts of WebKit's C++, the whole thing would
fall apart.

Why have we generated this using a custom action? The reason is that the
WebKit target already generated a header file for objective-C[++] to call
into Swift. There were a couple of reasons why we couldn't use that pre
existing file for non-objective C++:

* rdar://152836730: all the objective-C++ things need to be marked
  with #ifdef __OBJC__
* rdar://152838988: we need to be able to suppress the generation of
  WebPage because there's already a conflicting C++ class.

These fixes have now landed, so we can build a single header file which
supports both objective-C[++] and C++, and thus cease to generate an
extra header file using the custom action. But there are some toolchain
versions that we need to support which do not contain both of these fixes, so
for now this is conditional, and we retain the custom action for older SDKs.

The new approach is a pre-requisite to including more sophisticated Swift/C++
interoperability in WebKit, notably upcoming CoreIPC work. It won't be possible
to make that work with the old custom action approach.

A quirk of this change is that the source change for @_expose(!Cxx) is gated
not on #if GENERATE_SINGLE_SWIFT_INTEROP_FILE, but on #if compiler(>=6.2.3).
This is because older compilers still parse code inside #if statements, with
the exception of #if compiler. Older compilers get confused by
@_expose(!Cxx) so this is our only option.

Canonical link: https://commits.webkit.org/303315@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications

Reply via email to