If you're registering a rust enum as a component, then things can go wrong due to __enum_data_mut not being used in a thread safe manner. Or that's where I think the problem is.
In the codebase where I saw this, tests were running which basically just created a world and imported a module. This would then crash with errors like:
error: flecs.c: 7685: existing entity 'nx.window.components.WindowSize.size' is initialized with conflicting name 'Light'
fatal: flecs.c: 22368: assert: id != 0 Light (INVALID_OPERATION)
test module::tests::import_window_module ... ok
1 nx_window-8d96757ea4d2f0d2 0x0000000104fd16ec ecs_log_ + 260
2 nx_window-8d96757ea4d2f0d2 0x0000000104fca3ec ecs_assert_log_ + 224
3 nx_window-8d96757ea4d2f0d2 0x00000001050a0c74 ecs_cpp_enum_constant_register.cold.2 + 48
4 nx_window-8d96757ea4d2f0d2 0x0000000104fee798 ecs_cpp_enum_constant_register + 464
5 nx_window-8d96757ea4d2f0d2 0x0000000104f4e910 _ZN9flecs_ecs4core22component_registration12registration18register_enum_data17heb354870d53d8295E + 360
6 nx_window-8d96757ea4d2f0d2 0x0000000104f4f7e8 _ZN9flecs_ecs4core22component_registration12registration27internal_register_component17h49686996b0dd4dcdE + 184
7 nx_window-8d96757ea4d2f0d2 0x0000000104f40058 _ZN9flecs_ecs4core10components9component18Component$LT$T$GT$9new_named17h667045c5eaf1b1c2E + 2020
8 nx_window-8d96757ea4d2f0d2 0x0000000104f66234 _ZN9flecs_ecs4core5world5World15component_named17hc65f344ac8835a92E + 36
9 nx_window-8d96757ea4d2f0d2 0x0000000104f398ac _ZN95_$LT$nx_window..module..WindowComponentsModule$u20$as$u20$flecs_ecs..addons..module..Module$GT$6module17h1b92ec52742d604bE + 388
10 nx_window-8d96757ea4d2f0d2 0x0000000104f66874 _ZN9flecs_ecs6addons6module47_$LT$impl$u20$flecs_ecs..core..world..World$GT$6import17h54ddcbf58a6f40fcE + 1444
11 nx_window-8d96757ea4d2f0d2 0x0000000104f39b5c _ZN9nx_window6module5tests31import_window_components_module17hd55304a420157d27E + 36
12 nx_window-8d96757ea4d2f0d2 0x0000000104f58fdc _ZN9nx_window6module5tests31import_window_components_module28_$u7b$$u7b$closure$u7d$$u7d$17h40374661890f7ad3E + 24
13 nx_window-8d96757ea4d2f0d2 0x0000000104f59e94 _ZN4core3ops8function6FnOnce9call_once17ha607f62354219074E + 20
14 nx_window-8d96757ea4d2f0d2 0x0000000104fa0488 _ZN4test28__rust_begin_short_backtrace17hc42dc0fbb3b732f2E + 24
15 nx_window-8d96757ea4d2f0d2 0x0000000104f9f6e0 _ZN4test8run_test28_$u7b$$u7b$closure$u7d$$u7d$17ha080be6d5803b9daE + 716
16 nx_window-8d96757ea4d2f0d2 0x0000000104f6f0d0 _ZN3std3sys9backtrace28__rust_begin_short_backtrace17h09cb853678424d54E + 132
17 nx_window-8d96757ea4d2f0d2 0x0000000104f7230c _ZN4core3ops8function6FnOnce40call_once$u7b$$u7b$vtable.shim$u7d$$u7d$17h70f96de47595f3bdE + 124
18 nx_window-8d96757ea4d2f0d2 0x00000001050734b0 _ZN3std3sys3pal4unix6thread6Thread3new12thread_start17he7774aa0ca446eefE + 52
19 libsystem_pthread.dylib 0x000000019f2d82e4 _pthread_start + 136
20 libsystem_pthread.dylib 0x000000019f2d30fc thread_start + 8
error: test failed, to rerun pass `-p nx-window --lib`
Running a single test at a time doesn't have this issue.
If you're registering a rust enum as a component, then things can go wrong due to
__enum_data_mutnot being used in a thread safe manner. Or that's where I think the problem is.In the codebase where I saw this, tests were running which basically just created a world and imported a module. This would then crash with errors like:
Running a single test at a time doesn't have this issue.