This happens locally and on the EWS bots. Example is https://bugs.webkit.org/show_bug.cgi?id=165177. A clean build fixes the issue.
Most notably and frequently, removing things from Settings.in is a recipe for disaster.
When this happens, it happens on all bots. But in a couple of times I tried to reproduce this locally, this didn't reproduce.
So based on Said and Tim's comment it seems the main issue is Settings.in (and not JS bindings). I got confused because of "JS derived sources" in the title.
I saw this regularly when changing Settings.in. I think there's some issue with the generated .idl file that's used to create JSInternalSettingsGenerated.*
Note that I made some progress fixing this recently for JS: - https://trac.webkit.org/changeset/205913
I was able to reproduce this by removing a setting from Settings.in and rebuilding. I saw the following output in WebCore's Derived Sources build phase: perl WebCore/page/make_settings.pl --input WebCore/page/Settings.in make: Nothing to be done for `all'. Afterwards, InternalSettingsGenerated.h still had declarations for the setting I removed (shouldSuppressKeyboardInputDuringProvisionalNavigation). Make printed the command to bring InternalSettingsGenerated.h up-to-date, but didn't seem to actually run it.
Actually make_settings.pl did run, because SettingsMacros.h no longer contained the removed setting. It just seems like the internal generated settings weren't updated.
Very surprising that make_settings.pl was able to successfully modify SettingsMacros.h but not InternalSettingsGenerated.h. Perhaps the script failed part way through: The script does update SettingsMacros.h first, and then InternalSettingsGenerated.h later, but it seems like a peculiar symptom.
Is this a duplicate of bug 166814?
Yes it is a duplicate of 166814. *** This bug has been marked as a duplicate of bug 166814 ***