[webkit-changes] [WebKit/WebKit] 36392f: Merge WebKit swift overlay into WebKit.framework

[Elliott Williams]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 36392f6620ac514db4d182a707b719ef9aa9768f
      https://github.com/WebKit/WebKit/commit/36392f6620ac514db4d182a707b719ef9aa9768f
  Author: Elliott Williams <emw at apple.com>
  Date:   2024-10-27 (Sun, 27 Oct 2024)

  Changed paths:
    M Configurations/CommonBase.xcconfig
    M Source/WebKit/Configurations/Base.xcconfig
    M Source/WebKit/Configurations/BaseTarget.xcconfig
    M Source/WebKit/Configurations/WebKit.xcconfig
    M Source/WebKit/Configurations/WebKitSwift.xcconfig
    M Source/WebKit/Shared/API/Cocoa/WebKit.m
    R Source/WebKit/SwiftOverlay/SwiftOverlay/ObjectiveCBlockConversions.swift
    M Source/WebKit/SwiftOverlay/SwiftOverlay/install-swiftmodules.sh
    M Source/WebKit/SwiftOverlay/WebKitSwiftOverlay.xcodeproj/project.pbxproj
    A Source/WebKit/UIProcess/API/Cocoa/ObjectiveCBlockConversions.swift
    M Source/WebKit/UIProcess/API/Cocoa/WebKitSwiftOverlay.swift
    A Source/WebKit/UIProcess/Cocoa/WebKitSwiftOverlayMacros.h
    M Source/WebKit/WebKit.xcodeproj/project.pbxproj

  Log Message:
  -----------
  Merge WebKit swift overlay into WebKit.framework
https://bugs.webkit.org/show_bug.cgi?id=280734
rdar://119206029

Reviewed by Alexey Proskuryakov, Andy Estes, and Richard Robinson.

Instead of building a separate libswiftWebKit.dylib containing Swift
wrappers of WebKit APIs, implement those wrappers in WebKit's main
framework target. This frees up WebKit's Cocoa port to implement new
APIs in Swift which call into ObjC++ internals.

First, move the target membership of the overlay Swift sources to the
main target. Copy over relevant build settings from the overlay target
and from PAL, where we already have support for writing Swift wrappers.

The effect is that the main WebKit target now installs a
`WebKit.swiftmodule` into the OS, which is loaded when the Swift
compiler sees "import WebKit" and contains metadata telling the compiler
to link against WebKit.framework.

Next, retain binary compatibility for existing Swift clients of WebKit,
who have a runtime dependency on libswiftWebKit today. This works by:

- Emitting magic $ld$previous symbols into WebKit's const table for each
  symbol we are migrating from libswiftWebKit. Dyld uses the metadata in
  these symbols to fix up libswiftWebKit bindings to WebKit bindings.

- Installing a libswiftWebKit.dylib symlink
  which points to WebKit. Binaries which load libswiftWebKit will load
  WebKit directly. The dylib is moved to the system cryptex, so that it
  is picked up when building the dyld the shared cache. In the OS, the
  symlink will be resident in the shared cache at
  /usr/local/lib/libswiftWebKit.dylib (its old install name), and
  entirely removed from filesystem. The symlink is not installed in
  downlevels, which have never built the overlay.

Finally, now that WebKit produces its own swiftmodule, change the
WebKitSwiftOverlay project to produce a root with an empty
/usr/lib/swift directory. This avoids overlapping content in the OS
build, and means that any new Swift programs that use WebKit will link
directly to the main framework.

Eventually, we can stop building WebKitSwiftOverlay and delete it. There
are some tests in this project which aren't run by anyone currently, but
may be valuable to move to API tests once we have a viable way to write
API tests in Swift.

There are three follow-up changes needed to improve build coverage of
the overlay APIs:

- Declaring needed Network.framework SPI so that we can build the
  portion of the overlay that uses Network interfaces in public builds.
  (https://bugs.webkit.org/show_bug.cgi?id=280911)

- Fixing availability issues in tvOS and watchOS builds, to support
  building the overlay on those platforms. (https://bugs.webkit.org/show_bug.cgi?id=280912)
  It's not currently built there at all, but it will be nice to have
  parity on all platforms to support future Swift adoption.

- Fixing actor-isolation warnings in concurrent code. Currently, these
  warnings are ignored by the Swift overlay project in production
  builds. (https://bugs.webkit.org/show_bug.cgi?id=280734)

* Configurations/CommonBase.xcconfig: Satisfy style checker by making
  OTHER_SWIFT_FLAGS inherit, indicating that it's a list-style variable
  that is supposed to be appended to by other xcconfigs.
* Source/WebKit/Configurations/Base.xcconfig:
* Source/WebKit/Configurations/BaseTarget.xcconfig:
* Source/WebKit/Configurations/WebKit.xcconfig: In addition to migrated
  build settings, set SWIFT_LIBRARY_LEVEL because XCBuild can't infer
  whether WebKit is public or private due to its cryptex install path.
  Also set ASSETCATALOG_COMPILER_GENERATE_ASSET_SYMBOLS to avoid some
  generated Swift code as a side effect.
* Source/WebKit/Configurations/WebKitSwift.xcconfig:
* Source/WebKit/Shared/API/Cocoa/WebKit.m:
* Source/WebKit/SwiftOverlay/SwiftOverlay/install-swiftmodules.sh:
* Source/WebKit/SwiftOverlay/WebKitSwiftOverlay.xcodeproj/project.pbxproj:
* Source/WebKit/UIProcess/API/Cocoa/ObjectiveCBlockConversions.swift: Renamed from Source/WebKit/SwiftOverlay/SwiftOverlay/ObjectiveCBlockConversions.swift.
(ObjCBlockConversion.boxingNilAsAnyForCompatibility(_:Error:Error:)):
* Source/WebKit/UIProcess/Cocoa/WebKitSwiftOverlayMacros.h: Added.
* Source/WebKit/WebKit.xcodeproj/project.pbxproj:

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



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