Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 8a4f2c1e10436b245de90ca58cb16b4740d43ccc
https://github.com/WebKit/WebKit/commit/8a4f2c1e10436b245de90ca58cb16b4740d43ccc
Author: Elliott Williams <[email protected]>
Date: 2026-04-08 (Wed, 08 Apr 2026)
Changed paths:
M Source/WebKit/Configurations/AllowedSPI-legacy.toml
M Tools/Scripts/libraries/webkitapipy/webkitapipy/allow.py
M Tools/Scripts/libraries/webkitapipy/webkitapipy/allow_unittest.py
M Tools/Scripts/libraries/webkitapipy/webkitapipy/program.py
M Tools/Scripts/libraries/webkitapipy/webkitapipy/sdkdb.py
M Tools/Scripts/libraries/webkitapipy/webkitapipy/sdkdb_unittest.py
A Tools/Scripts/libraries/webkitapipy/webkitapipy/swift_mangle.py
A Tools/Scripts/libraries/webkitapipy/webkitapipy/swift_mangle_unittest.py
Log Message:
-----------
[audit-spi] Swift symbols can change between SDK builds, breaking allowlists
https://bugs.webkit.org/show_bug.cgi?id=309970
rdar://172677139
Reviewed by Mike Wyrzykowski and Sam Sneddon.
Swift makes it relatively easy for library authors to make
source-compatible but ABI-breaking changes, and for SPI (where there is
no implicit contract to retain binary compatibility) we observe changes
to symbol names in between SDK builds, as OS frameworks submit new
versions. This causes our allowlists to go out of date despite no change
in our SPI footprint, disrupting CI and driving frustration with the
tools.
Work towards improving how we declare Swift SPI in allowlists by
supporting a higher-level syntax for naming the Swift declarations we
use. Instead of needing to declare the exact mangled symbol used,
allowlists recognize a "swift-decl" section that lists nominal types and
method names that we are using. For example, instead of writing:
symbols =
["$s5UIKit16UITextEffectViewC015ReplacementTextC0C5chunk4view8delegate9fromColorAeA0bcF5ChunkC_AcE8Delegate_pSo7UIColorCtcfC"]
we can write:
swift-decls = [
{ name =
"UIKit.UITextEffectView.PonderingEffect.init(chunk:view:lightConfiguration:)" }
]
A "partial name mangler" based on the Swift compiler's own name mangling
spec <https://github.com/swiftlang/swift/blob/main/docs/ABI/Mangling.rst>
parses these nominal types and produces the expected *prefix* that the
real symbol starts with.
Objects which are fully SPI can be matched by only writing the type
name. This entry matches the SomeSPIClass type and all its member
functions:
{ name = "ModuleName.SomeSPIClass" }
Additionally, function declarations can omit their parameter names to
match functions/initializers with arbitrary parameters:
{ name = "UIKit.UITextEffectView.PonderingEffect.init()" }
Entries support some additional fields which customize the partial
symbol generated. A complete example:
{ name =
"UIKit.UITextEffectView.ReplacementTextEffect.Delegate.performAnimatedReplacement(for:effect:animation:)",
# Maps components of the nominal type to their declaration kinds (struct,
protocol, enum, class).
type_kinds = { "Delegate" = "protocol" },
# If the declaration is an extension, the extension is part of
# this module.
extension = "UIKit",
# How deeply nested in the nominal type the extension occurs. For
example, this entry matches a symbol
# `performAnimatedReplacement` on an `extension
UIKitCore.UITextEffectView.ReplacementTextEffect.Delegate { ... }` declaration.
extension_base_depth = 3 },
The sdkdb engine uses these partial symbols to make prefix queries
against the table of imported symbols. The same rules about unused
allowlist entries still apply; a Swift declaration that does not match
against any imported symbols is flagged.
For performance reasons, refactor SDKDB.audit() and split the query into
multiple steps:
1. First, it prepares the table of active conditions.
2. Then, it subtracts the `exports` from `imports` to find potential SPI
in imported binaries.
3. Then, it joins allowlist entries to `imports` to find potential SPI
which are covered by an allowlist.
4. The results of steps 2 and 3 are compared to produce the different
diagnostic classes.
Canonical link: https://commits.webkit.org/310820@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
