Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 3ecd1b1c515adcbf7a796fa3f39a7a9c9e1a9d14
https://github.com/WebKit/WebKit/commit/3ecd1b1c515adcbf7a796fa3f39a7a9c9e1a9d14
Author: Richard Robinson <[email protected]>
Date: 2025-10-06 (Mon, 06 Oct 2025)
Changed paths:
M Source/bmalloc/Configurations/module.modulemap
M Source/bmalloc/libpas/src/libpas/pas_lock.h
Log Message:
-----------
[Swift in WebKit] The bmalloc module map is malformed (must include
pas_lock.h)
https://bugs.webkit.org/show_bug.cgi?id=300198
rdar://161993222
Reviewed by Mark Lam.
Currently, (in Cocoa configurations at least) bmalloc depends on its client
setting `OS_UNFAIR_LOCK_INLINE` to `1`;
otherwise, a compilation error happens. However, modules require that
libraries/frameworks are usable without any
explicit configuration set. Therefore, bmalloc must at least be able to compile
all its translation units regardless
of the value of `OS_UNFAIR_LOCK_INLINE`.
To workaround this, the `pas_lock.h` file was initially excluded from the
module map. However, this is invalid as
it results in modular headers then including non-modular headers, which is a
violation. This has not been a problem
so far because (a) there is no automatic module verification for libraries and
(b) there is yet a Swift/Cxx interop
include path in WebKit or WebCore that depends on a file that uses `bmalloc`.
Manually performing module verification
does reveal this issue, which is a violation and needs to be remedied.
To fix, the `#error` directive must be removed so that bmalloc can be built
regardless of the value of `OS_UNFAIR_LOCK_INLINE`.
Consequently, some more compilation conditions have to be added to the file to
account for configurations where
`OS_UNFAIR_LOCK_INLINE` is `0` since the relevant locking APIs from the system
are unavailable.
In actuality, these paths where `OS_UNFAIR_LOCK_INLINE` is `0` will never
actually be executed; they just need to
be able to compile.
Since this is technically a slight change of behavior, there are several safe
guards added:
1. There are currently no Cocoa bmalloc clients that set
`OS_UNFAIR_LOCK_INLINE` to `0` or leave it undefined
2. If, for some reason, one of the existing clients changed the value from `1`
to `0`, a compiler diagnostic message
will be emitted with the same message as the error would have given.
3. The invalid branches are limited in scope, and immediately cause a release
assertion if triggered.
One alternative considered was to wrap every header and translation unit in
bmalloc with a compile time guard; this
was decided against because although this would technically not be a change in
behavior for bmalloc, the changes would
be quite extensive and intrusive. Additionally, this would just move the issue
up one dependency to the client of bmalloc anyways.
* Source/WebKit/Configurations/WebKit.xcconfig:
* Source/bmalloc/Configurations/module.modulemap:
* Source/bmalloc/libpas/src/libpas/pas_lock.h:
(pas_lock_lock):
(pas_lock_try_lock):
(pas_lock_unlock):
Canonical link: https://commits.webkit.org/301104@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
