src/p_acs.cpp:3250:75: error: cannot pass object of non-trivial type 'FString' through variadic constructor; call will abort at runtime [-Wnon-pod-varargs]
src/p_conversation.cpp:354:56: error: cannot pass object of non-trivial type 'FString' through variadic constructor; call will abort at runtime [-Wnon-pod-varargs]
src/p_conversation.cpp:438:51: error: cannot pass object of non-trivial type 'FString' through variadic constructor; call will abort at runtime [-Wnon-pod-varargs]
src/p_conversation.cpp:548:58: error: cannot pass object of non-trivial type 'FString' through variadic constructor; call will abort at runtime [-Wnon-pod-varargs]
src/p_conversation.cpp:572:59: error: cannot pass object of non-trivial type 'FString' through variadic constructor; call will abort at runtime [-Wnon-pod-varargs]
src/p_conversation.cpp:584:58: error: cannot pass object of non-trivial type 'FString' through variadic constructor; call will abort at runtime [-Wnon-pod-varargs]
Thanks to the lazy counter it used in its stat display I never noticed that the serializer was incomplete and that UnlinkFromMap did not call its super method.
After changing the counter to be actively counting on each call, all the other issues became immediately apparent.
The interpolator had been changed long ago to use proper GC tracking, so interpolations only can get collected if they had been fully orphaned.
This comment was the main reason why the design flaw in this code never got fixed until recently.
It seems there can be rare conditions where an interpolation is 'lost' and later garbage collected. If that happens after the owning map is gone, all pointers in the interpolation object will be invalid and Destroy would crash while trying to unlink it. So anything that explicitly deletes an interpolation now has to manually unlink it from the map first so that OnDestroy can be kept clean of map references.
Now all this content can be localized. However, since this is actual game content it was placed in a secondary file in zd_extra.pk3, so that it won't affect the GPL-compatible status of the main one.
src/posix/cocoa/i_input.mm:95:22: error: use of undeclared identifier 'E_CheckUiProcessors'
src/posix/cocoa/i_input.mm:200:21: error: use of undeclared identifier 'E_CheckRequireMouse'
src/posix/sdl/i_input.cpp:183:19: error: use of undeclared identifier 'E_CheckUiProcessors'
src/events.cpp:540:1: error: pasting formed '::RenderFrame', an invalid preprocessing token
src/events.cpp:541:1: error: pasting formed '::WorldLightning', an invalid preprocessing token
src/events.cpp:542:1: error: pasting formed '::WorldTick', an invalid preprocessing token
src/events.cpp:543:1: error: pasting formed '::UiTick', an invalid preprocessing token
src/events.cpp:544:1: error: pasting formed '::PostUiTick', an invalid preprocessing token
The software renderer does not have any safeguards against such a mapping and crashes on it.
This code was a quick hack from ancient times from when ZDoom did not have robust texture management and some recent changes ran afoul of this very special exception.
Having everything lumped together made this a maintenance hassle because it affected how the level has to be stored.
This hasn't been tested yet, so it may not work as intended!
The original place in I_CheckNativeMouse is unsafe because that function can get called from the system message queue which can result in a bad global state of the VM for such a call because it can be recursively invoked from code that may temporarily alter some settings.
Christoph Oelckers
Major Cooke
Rachael Alexanderson
alexey.lysiuk
Alexander
Nemrtvi