Bug 306415 – Invent and enforce scheme to mark which WebKit headers are "above" or "below" Swift

• Status: NEW
• Component: WebKit Misc.

WebKit is adding Swift code as part of its internals.

WebKit's Swift code depends on some WebKit C++ headers. Those headers are interpreted as the WebKit_Internal clang module, and their types and functions are made available to Swift code.

The types and functions within that Swift code is then itself represented as a header, WebKit-Swift-Generated.h, upon which other parts of WebKit depend.

It would be easy to get into a muddle and cause a circular dependency here, where:

[WebThingy.h] --depends on--> [WebKit-Swift-Generated.h] --built from--> [WebThingy.swift] --depends on--> [WebKit_Internal module] --which contains--> [WebThingy.h]

To avoid this, WebKit's Swift code is currently sticking to a rule that ONLY .cpp files are allowed to include WebKit-Swift-Generated.h. (There's a slight tweak to this rule that they actually include WebKit-Swift.h, which includes WebKit-Swift-Generated.h, but WebKit-Swift.h is the ONLY header permitted to include WebKit-Swift-Generated.h).

This rule works, in the sense that it avoids the risk of circular dependencies, but it has three problems:

1) we need to include WebKit-Swift.h from LOTS of .cpp files. (Any .cpp file which calls a function or uses a type defined in Swift). Code review feedback on https://github.com/WebKit/WebKit/pull/57288 suggests this is basically not OK long-term.

2) it means that our C++ data types defined in .h files cannot include Swift types. The most they can do is use a std::unique_ptr<SomeSwiftType> so that header files need only rely on a forward declaration. This obviously causes more heap allocations, ugliness, and indirections.

3) there's no enforcement mechanism. Someone might start to include WebKit-Swift.h or WebKit-Swift-Generated.h from a header file, and there's nothing to stop that until we get weird inscrutable build errors later.


We could instead come up with a better scheme where some WebKit headers are regarded as "above" Swift and some "below" Swift.

For example,
WebPageProxy.h [above Swift] may want a reference to the Swift WebBackForwardList, so is allowed to include WebKit-Swift.h
Swift code is not allowed to rely on WebPageProxy.h, but is allowed to rely on...
WebBackForwardListItem.h [below Swift]

Perhaps we can have an enforcement mechanism using macros or some clang module facility that I'm not aware of.

From the point of view of clang modules, I guess this means that only the stuff "below Swift" should go into the WebKit_Internal module.

Related issues:
rdar://162862737 is the internal Apple issue on the Swift/C++ interop team representing this general awkwardness
rdar://165068038 is a narrower issue stating that we don't have a lot of control over the generation of WebKit-Swift.h.