Bug 186273

Summary:	-fvar-tracking-assignments warning from BuiltinNames.cpp
Product:	WebKit	Reporter:	Michael Catanzaro <mcatanzaro>
Component:	JavaScriptCore	Assignee:	Nobody <webkit-unassigned>
Status:	RESOLVED CONFIGURATION CHANGED
Severity:	Normal	CC:	ap, mcatanzaro, ross.kirsling
Priority:	P2
Version:	WebKit Nightly Build
Hardware:	PC
OS:	Linux

Description Michael Catanzaro 2018-06-04 09:35:28 PDT

This is annoying:

[272/1837] Building CXX object Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/__/__/DerivedSources/JavaScriptCore/unified-sources/UnifiedSource24.cpp.o
In file included from DerivedSources/JavaScriptCore/unified-sources/UnifiedSource24.cpp:3:
/home/mcatanzaro/Projects/WebKit/Source/JavaScriptCore/builtins/BuiltinNames.cpp: In constructor ‘JSC::BuiltinNames::BuiltinNames(JSC::VM*, JSC::CommonIdentifiers*)’:
/home/mcatanzaro/Projects/WebKit/Source/JavaScriptCore/builtins/BuiltinNames.cpp:53:1: note: variable tracking size limit exceeded with -fvar-tracking-assignments, retrying without
 BuiltinNames::BuiltinNames(VM* vm, CommonIdentifiers* commonIdentifiers)
 ^~~~~~~~~~~~

I tried to fix it a few weeks ago by moving the code from BuiltinNames.h to BuiltinNames.cpp, and adding some code to Source/JavaScriptCore/CMakeLists.txt:

# Avoid "variable tracking size limit exceeded"
set_source_files_properties(builtins/BuiltinNames.cpp PROPERTIES COMPILE_FLAGS -fno-var-tracking-assignments)

I thought that fixed it, but in fact it does nothing since BuiltinNames.cpp is not a build target... UnifiedSource24.cpp is the real build target. Drat. The warning went away for me because the file was simply not recompiled, because its build flags did not change like I thought they had, tricking me into thinking I had fixed it.

This will probably be tricky to fix. We could add a CMake macro to propagate compiler flags from a given source file to the corresponding unified source file, or we could just rewrite the BuiltinNames constructor (probably saner).

Comment 1 Michael Catanzaro 2018-06-04 09:42:40 PDT

We should probably also audit other uses of set_source_file_properties as they're likely broken:

JavaScriptCore/CMakeLists.txt:    set_source_files_properties(builtins/BuiltinNames.cpp PROPERTIES COMPIL
E_FLAGS -fno-var-tracking-assignments)
JavaScriptCore/shell/PlatformMac.cmake:set_source_files_properties(${TESTAPI_OBJC_SOURCES} PROPERTIES COM
PILE_FLAGS -fobjc-arc)
JavaScriptCore/shell/PlatformWin.cmake:set_source_files_properties(../API/tests/CustomGlobalObjectClassTe
st.c PROPERTIES COMPILE_FLAGS "/TP")
JavaScriptCore/shell/PlatformWin.cmake:set_source_files_properties(../API/tests/testapi.c PROPERTIES COMP
ILE_FLAGS "/TP")
ThirdParty/libwebrtc/Source/third_party/protobuf/cmake/protobuf-module.cmake.in:  set_source_files_proper
ties(${${SRCS}} ${${HDRS}} PROPERTIES GENERATED TRUE)
ThirdParty/openvr/src/CMakeLists.txt:    set_source_files_properties(vrcommon/pathtools_public.cpp vrcomm
on/vrpathregistry_public.cpp PROPERTIES COMPILE_FLAGS "
-x objective-c++")
WebCore/ChangeLog-2015-11-21:        because CMake can only set COMPILE_FLAGS once with set_source_files_properties, and we want 
WebCore/PlatformGTK.cmake:    set_source_files_properties(${DERIVED_SOURCES_WEBCORE_DIR}/Geoclue2Interface.c PROPERTIES COMPILE_FLAGS -Wno-unused-parameter)
WebCore/platform/GStreamer.cmake:    set_source_files_properties(platform/audio/gstreamer/WebKitWebAudioSourceGStreamer.cpp PROPERTIES COMPILE_DEFINITIONS "GLIB_DISABLE_DEPRECATION_WARNINGS=1")
WebKitLegacy/PlatformMac.cmake:        set_source_files_properties(${_file} PROPERTIES COMPILE_FLAGS "-ObjC++ -std=c++17")
WebKitLegacy/PlatformMac.cmake:        set_source_files_properties(${_file} PROPERTIES COMPILE_FLAGS -std=c99)
WebKitLegacy/PlatformWin.cmake:    set_source_files_properties(${DERIVED_SOURCES_WEBKITLEGACY_DIR}/Interfaces/${_filewe}.h PROPERTIES GENERATED TRUE)
WebKitLegacy/PlatformWin.cmake:    set_source_files_properties(${DERIVED_SOURCES_WEBKITLEGACY_DIR}/Interfaces/${_filewe}_i.c PROPERTIES GENERATED TRUE)
cmake/WebKitMacros.cmake:        set_source_files_properties(${_sourceFileTmp} PROPERTIES HEADER_FILE_ONLY ON)
cmake/WebKitMacros.cmake:    set_source_files_properties(${_source} PROPERTIES OBJECT_DEPENDS "${_tmp}")
cmake/WebKitMacros.cmake:            set_source_files_properties(${_cpp}
cmake/WebKitMacros.cmake:            set_source_files_properties(${_cpp}
cmake/WebKitMacros.cmake:        set_source_files_properties(${_sources}

Comment 2 Michael Catanzaro 2018-11-16 05:05:08 PST

I tried to change BuiltinNames.cpp so it would be built non-unified, but I couldn't get it to li nk, and I didn't understand why.

Comment 3 Michael Catanzaro 2019-04-08 13:01:53 PDT

(In reply to Michael Catanzaro from comment #1)
> We should probably also audit other uses of set_source_file_properties as
> they're likely broken:

Bug #196703

Comment 4 Ross Kirsling 2019-04-08 13:23:31 PDT

Closing per the suggestion in bug 196699 comment 3 that this issue no longer occurs with GCC 9.