The RNA CustomDataLayer api stores pointers to CustomDataLayer structs in the
PointerRNA, but when CustomData layers are added/removed those get reordered.
This leads to pythons MeshUVLoopLayer referencing the wrong layer. Potentially
even pointing into freed memory.
see #107500
This patch is a 'proof of concept' and is unfinished in a few ways:
- Only MeshUVLoopLayers are handled, other CustomDataLayer accesses
(attributes, vertex_create, vertex_color etc etc) are still broken, possibly
*more* broken.
- The indirection table used is currently hardcoded to 64 entries. This will
crash & burn whenever there are more than 64 simultaneous customdata layers.
Possible ways to move forward:
- Don't use an indirection table, use a unique id on every CustomDataLayer
and do a search for every access. This is slower, but the speeds maybe not
too important for the layer lookups, as long as the element access still is
fast.
- Store the indirection table in a (to be created) C++ array-like type without
reallocation.
- Ignore this problem for 3.6 and for 4.0 redesign attribute/customdata storage
in a way that the layer(-header)s don't move around.