Bug 282275 – [CMake] C compiler flags improperly used when compiling libpas source files as C++

• Component: bmalloc
• Status: RESOLVED FIXED

[Michael Catanzaro]

Berto is complaining about this warning when compiling e.g. bmalloc_heap_config.c:

/usr/bin/cc -DBUILDING_GTK__=1 -DBUILDING_WEBKIT=1 -DBUILDING_WITH_CMAKE=1 -DBUILDING_bmalloc -DBWRAP_EXECUTABLE=\"/usr/bin/bwrap\" -DDBUS_PROXY_EXECUTABLE=\"/usr/bin/xdg-dbus-proxy\" -DGETTEXT_PACKAGE=\"WebKitGTK-4.1\" -DHAVE_CONFIG_H=1 -DJSC_GLIB_API_ENABLED -DPAS_BMALLOC=1 -D_GNU_SOURCE -I/tmp/webkit2gtk-2.47.1/Source/bmalloc -I/tmp/webkit2gtk-2.47.1/Source/bmalloc/bmalloc -I/tmp/webkit2gtk-2.47.1/Source/bmalloc/libpas/src/libpas -fdiagnostics-color=always -Wextra -Wall -pipe -fmax-errors=20 -Wno-expansion-to-defined -Wno-psabi -Wno-misleading-indentation -Wno-maybe-uninitialized -Wundef -Wpointer-arith -Wmissing-format-attribute -Wformat-security -Wcast-align -Wno-tautological-compare -g1 -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/tmp/webkit2gtk-2.47.1=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 -DNDEBUG -DG_DISABLE_CAST_CHECKS -fno-strict-aliasing -fno-exceptions -ffunction-sections -fdata-sections -fPIC -fvisibility=hidden -Wno-missing-field-initializers -Wno-cast-align -xc++ -std=c++2b -MD -MT Source/bmalloc/CMakeFiles/bmalloc.dir/libpas/src/libpas/bmalloc_heap_config.c.o -MF Source/bmalloc/CMakeFiles/bmalloc.dir/libpas/src/libpas/bmalloc_heap_config.c.o.d -o Source/bmalloc/CMakeFiles/bmalloc.dir/libpas/src/libpas/bmalloc_heap_config.c.o -c /tmp/webkit2gtk-2.47.1/Source/bmalloc/libpas/src/libpas/bmalloc_heap_config.c
cc1plus: warning: ‘-Werror=’ argument ‘-Werror=implicit-function-declaration’ is not valid for C++

Problem is a few libpas files are manually compiled with -xc++ -std=c++2b, but CMake doesn't know about this so it uses CFLAGS and CMAKE_C_FLAGS rather than CXXFLAGS and CMAKE_CXX_FLAGS. We can simply tell CMake to change the programming language rather than attempt to change this by passing -xc++ to the C compiler. This works since CMake 3.20, which is conveniently the minimum version that we support. (And we already set CMAKE_CXX_STANDARD to 23, so no need for -std=c++2b anymore either.)

I wonder why C++ is used at all. It's quite unusual to compile C source files as C++ without some explanation in the code or build system for why this is done. The code clearly does not use any C++. But I assume there's some good reason for this?

[Michael Catanzaro]

Pull request: https://github.com/WebKit/WebKit/pull/35892

[Michael Catanzaro]

Mystery solved: those files really are C++ and won't build as C:

/app/webkit/Source/bmalloc/libpas/src/libpas/pas_bitfit_page_config_kind.c:74:5: error: initializer element is not constant
   74 |     (value).base.page_config_ptr,
      |     ^
/app/webkit/Source/bmalloc/libpas/src/libpas/pas_bitfit_page_config_kind.def:43:1: note: in expansion of macro ‘PAS_DEFINE_BITFIT_PAGE_CONFIG_KIND’
   43 | PAS_DEFINE_BITFIT_PAGE_CONFIG_KIND(
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/app/webkit/Source/bmalloc/libpas/src/libpas/pas_bitfit_page_config_kind.c:74:5: note: (near initialization for ‘pas_bitfit_page_config_kind_for_config_table[0]’)
   74 |     (value).base.page_config_ptr,
      |     ^
/app/webkit/Source/bmalloc/libpas/src/libpas/pas_bitfit_page_config_kind.def:43:1: note: in expansion of macro ‘PAS_DEFINE_BITFIT_PAGE_CONFIG_KIND’
   43 | PAS_DEFINE_BITFIT_PAGE_CONFIG_KIND(
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I guess the .c is there to discourage most other use of C++.

[EWS]

Committed 285901@main (6641652afa8a): <https://commits.webkit.org/285901@main>

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

[Radar WebKit Bug Importer]

<rdar://problem/138916440>