Skip to content

[CMake] Swift typecheck step races _CopyHeaders on clean builds#65537

Merged
webkit-commit-queue merged 1 commit into
WebKit:mainfrom
stwrt:eng/fix_the_build_cmake
May 24, 2026
Merged

[CMake] Swift typecheck step races _CopyHeaders on clean builds#65537
webkit-commit-queue merged 1 commit into
WebKit:mainfrom
stwrt:eng/fix_the_build_cmake

Conversation

@stwrt
Copy link
Copy Markdown
Contributor

@stwrt stwrt commented May 23, 2026

04934ae

[CMake] Swift typecheck step races _CopyHeaders on clean builds
https://bugs.webkit.org/show_bug.cgi?id=315424
rdar://177781369

Reviewed by Adrian Taylor and Geoffrey Garen.

On a clean build, the PAL Swift C++-interop typecheck step intermittently
fails with:

    error: underlying Objective-C module 'pal' not found
    @_exported public import pal
    error: no such module 'pal.Core.crypto.CryptoTypes'

The same step succeeds on the next build. Root cause is a missing edge in
the ninja graph: `_webkit_setup_swift_header_deps` collects the framework's
`_CopyHeaders` / `_CopyPrivateHeaders` targets into `${_deps}` and attaches
them only to the outer `${_target}_SwiftCxxHeader` ordering target. That
gates the framework's main Swift compilation, but not the
`add_custom_command(OUTPUT ${_stamp} ...)` that runs `swiftc -typecheck`
to emit the C++ interop header. The typecheck command's DEPENDS list is
`${_swift_sources} ${_target}_SwiftGeneratedDeps`, where
`_SwiftGeneratedDeps` carries only binary-dir headers from
`${_target}_HEADERS` / `${_target}_DERIVED_SOURCES`.

Source-tree headers staged via `_CopyHeaders` (e.g.
`PAL/Headers/pal/crypto/CryptoTypes.h`) are therefore not inputs to the
typecheck node. Ninja can schedule the typecheck before the framework's
umbrella header directory is fully populated, at which point Clang's
`umbrella "."` discovery in the staged module.modulemap fails to resolve
the imports requested by pal.swift's `import pal.Core.crypto.CryptoTypes`.

Add the `_CopyHeaders` targets as dependencies of `_SwiftGeneratedDeps`
so the typecheck node itself waits for header staging, not just the outer
`_SwiftCxxHeader` target. The fix is symmetric across PAL, WebGPU, etc.;
all consumers of `WEBKIT_SETUP_SWIFT_AND_GENERATE_SWIFT_CPP_INTEROP_HEADER`
benefit.

* Source/cmake/WebKitMacros.cmake:

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

757de42

Misc iOS, visionOS, tvOS & watchOS macOS Linux Windows Apple Internal
✅ 🧪 style ✅ 🛠 ios 🛠 mac 🛠 wpe ✅ 🛠 win ⏳ 🛠 ios-apple
✅ 🛠 ios-sim ✅ 🛠 mac-AS-debug 🧪 wpe-wk2 🧪 win-tests ⏳ 🛠 mac-apple
✅ 🧪 webkitperl 🧪 ios-wk2 🧪 api-mac 🧪 api-wpe ⏳ 🛠 vision-apple
🧪 ios-wk2-wpt 🧪 api-mac-debug 🛠 gtk3-libwebrtc
✅ 🛠 🧪 jsc-x86-64 🧪 api-ios 🛠 gtk
✅ 🛠 🧪 jsc-debug-arm64 🧪 mac-wk2 🧪 gtk-wk2
✅ 🛠 vision 🧪 mac-AS-debug-wk2 🧪 api-gtk
✅ 🛠 vision-sim 🧪 mac-wk2-stress ✅ 🛠 playstation
✅ 🛠 🧪 unsafe-merge 🧪 vision-wk2 🧪 mac-intel-wk2 ✅ 🛠 jsc-armv7
✅ 🛠 tv 🧪 jsc-armv7-tests
✅ 🛠 tv-sim 🧪 mac-site-isolation
✅ 🛠 watch
✅ 🛠 watch-sim

@stwrt stwrt self-assigned this May 23, 2026
@stwrt stwrt added the Tools / Tests Tools in the Tools directory, build issues, test infrastructure, and bugs in test cases label May 23, 2026
@stwrt stwrt requested review from adetaylor and geoffreygaren May 23, 2026 14:51
Comment thread Source/cmake/WebKitMacros.cmake Outdated
Comment on lines +849 to +855
# The typecheck command that produces ${_stamp} only DEPENDS on
# ${_target}_SwiftGeneratedDeps (binary-dir headers). On a clean first
# build ninja can schedule it before _CopyHeaders has finished staging
# source-tree headers under <framework>/Headers/, leaving the umbrella
# modulemap pointing at a partial directory. swiftc then fails with
# "underlying Objective-C module '<module>' not found". Gate the
# typecheck on _CopyHeaders too.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's remove this comment. I don't find it helpful. It's an execution trace of how the code would behave if it were written differently, and then what would go wrong in that other code. That doesn't really explain this code. And I think the code is reasonably self-explanatory, and if it isn't I can always review the commit message.

Copy link
Copy Markdown
Contributor

@adetaylor adetaylor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - please could you review #65122 too?

@stwrt stwrt force-pushed the eng/fix_the_build_cmake branch from bd0863f to 757de42 Compare May 24, 2026 02:54
@stwrt stwrt added the unsafe-merge-queue Applied to send a pull request to merge-queue, but skip building and testing label May 24, 2026
https://bugs.webkit.org/show_bug.cgi?id=315424
rdar://177781369

Reviewed by Adrian Taylor and Geoffrey Garen.

On a clean build, the PAL Swift C++-interop typecheck step intermittently
fails with:

    error: underlying Objective-C module 'pal' not found
    @_exported public import pal
    error: no such module 'pal.Core.crypto.CryptoTypes'

The same step succeeds on the next build. Root cause is a missing edge in
the ninja graph: `_webkit_setup_swift_header_deps` collects the framework's
`_CopyHeaders` / `_CopyPrivateHeaders` targets into `${_deps}` and attaches
them only to the outer `${_target}_SwiftCxxHeader` ordering target. That
gates the framework's main Swift compilation, but not the
`add_custom_command(OUTPUT ${_stamp} ...)` that runs `swiftc -typecheck`
to emit the C++ interop header. The typecheck command's DEPENDS list is
`${_swift_sources} ${_target}_SwiftGeneratedDeps`, where
`_SwiftGeneratedDeps` carries only binary-dir headers from
`${_target}_HEADERS` / `${_target}_DERIVED_SOURCES`.

Source-tree headers staged via `_CopyHeaders` (e.g.
`PAL/Headers/pal/crypto/CryptoTypes.h`) are therefore not inputs to the
typecheck node. Ninja can schedule the typecheck before the framework's
umbrella header directory is fully populated, at which point Clang's
`umbrella "."` discovery in the staged module.modulemap fails to resolve
the imports requested by pal.swift's `import pal.Core.crypto.CryptoTypes`.

Add the `_CopyHeaders` targets as dependencies of `_SwiftGeneratedDeps`
so the typecheck node itself waits for header staging, not just the outer
`_SwiftCxxHeader` target. The fix is symmetric across PAL, WebGPU, etc.;
all consumers of `WEBKIT_SETUP_SWIFT_AND_GENERATE_SWIFT_CPP_INTEROP_HEADER`
benefit.

* Source/cmake/WebKitMacros.cmake:

Canonical link: https://commits.webkit.org/313799@main
@webkit-commit-queue webkit-commit-queue force-pushed the eng/fix_the_build_cmake branch from 757de42 to 04934ae Compare May 24, 2026 02:56
@webkit-commit-queue
Copy link
Copy Markdown
Collaborator

Committed 313799@main (04934ae): https://commits.webkit.org/313799@main

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

@webkit-commit-queue webkit-commit-queue merged commit 04934ae into WebKit:main May 24, 2026
@webkit-commit-queue webkit-commit-queue removed the unsafe-merge-queue Applied to send a pull request to merge-queue, but skip building and testing label May 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Tools / Tests Tools in the Tools directory, build issues, test infrastructure, and bugs in test cases

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants