Bug 306515 – Swift Back Forward List - ownership and basic object layout

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit Process Model

We are building a Swift version of the Back Forward List code. For the general structure and motivation, see https://github.com/WebKit/WebKit/pull/55393.

This bug represents the PR which adds the basic object model and ownership.

In this bit we will add:
* Skeleton of Swift WebBackForwardList file
* WebBackForwardListWrapper C++ API shim object
* Accessors within WebPageProxy for three different objects
* Use of those accessors instead of direct access to m_backForwardList.

In this commit, we introduce a nearly-blank WebBackForwardList.swift with just enough code to represent the object ownership relationships.

This commit does not contain:
* All the actual function bodies we'll add to the Swift code
* Various Swift conformances and utility functions
* A 'SwiftUtilities.h' file which represents some types used in Swift, and
  adds some C++ wrapper functions.

The goal of this separate submission is to make the ownership easily reviewable.

There should be no functional changes unless ENABLE_BACK_FORWARD_LIST_SWIFT is set.

As well as the Swift WebBackForwardList, we add a C++ WebBackForwardListWrapper. (If ENABLE_BACK_FORWARD_LIST_SWIFT is disabled, these types are synonymous).

This type exists because Swift types cannot yet inherit from C++ type hierarchies (this limitation is tracked as rdar://105042781). For that reason, introducing Swift Back Forward List results in us needing two types:

* WebBackForwardList (Swift)
* WebBackForwardListWrapper (C++)

This is unfortunate, and is the biggest annoyance in using Swift for the Back Forward List. Nevertheless, the shim is very small and simple.

Naming:
The Swift implementation type must be called WebBackForwardList, because it will come to handle IPC messages directly and therefore it must match the name of the IPC receiver as defined in WebBackForwardList.messages.in. The C++ API shim could be called WebBackForwardListAPIImpl, WebBackForwardListShim, WebBackForwardListWrapper etc. Reviewers have a preference for the latter so that's what we've got.

Its methods cannot be inline because only C++ implementation files are permitted to include WebKit-Swift.h, to avoid the risk of dependency loops as swiftc parses our headers to generate WebKit-Swift.h.

Alternatives considered:
* Reimplement API::Object hierarchy in Swift, or make a parallel Swift hierarchy - we may do this in subsequent work
* Use a similar approach to the WebGPU work where we don't really have a Swift type, but instead Swift extensions to a pre-existing C++ type. Ruled out because then we don't store data/stage in Swift and it's not a representative use of Swift in the WebKit codebase.

This commit adds methods to WebPageProxy which return either the
* WebBackForwardListWrapper - the API type exposing only high-level APIs.
* WebBackForwardList - the implementation type (which contains richer internal functionality)
* The message receiver object (autogenerated by code in prior PRs)

These accessor methods are used everywhere where the m_backForwardList field was used directly - if ENABLE_BACK_FORWARD_LIST_SWIFT is disabled, all three accessors return the same object. The message receiver is in autogenerated code produced from WebBackForwardList.messages.in by messages.py.

[Radar WebKit Bug Importer]

<rdar://problem/169172203>

[EWS]

Committed 306412@main (180e9f85ddca): <https://commits.webkit.org/306412@main>

Reviewed commits have been landed. Closing PR #57285 and removing active labels.