GCC false-positives for Werror=maybe_uninitialized

[jleibs]

Overview

We have a handful of places where we need to disabled -Wmaybe-uninitialized primarily related to usage of std::optional.

It seems that move-assigning to the std::optional can lead to situations where gcc thinks we are using uninitialized-memory because the memory in the optional hasn't been initialized.

This issue is to track those usages and maybe review or better work around them in the future.

Archetypes

• Inside of with_component() builders, the std::move(*this) move-constructs from a possible uninitialized optional. This sadly needs to be code-generated into every archetype.

ComponentBatches

• Inside the move-assignment, the call to this->swap(other); seems like it's possibly happening on uninitialized memory. This one in particular seems suspicious.

TranslationRotationScale

• Contains optional union-types that seem to cause problems during copy-construction.

Future Work

I suspect one approach to mitigating these would be to avoid some of our usages of swap. We aren't required to swap data back into the moved-from objects. Rather we should free anything necessary immediately (rather than counting on the moved-from-r-values destructor), copy the data over from the r-value, and then explicitly set it to an uninitialized state.

[Wumpf]

The problem with with_component on archetypes went away with eager serialization. Those suppressions got removed in

• Remove attr.cpp.archetype_eager codegen attribute #8780

Others are still around. Might need another pass.