In use-after-despawn situation, make despawning system name available

[payload]

This draft sketches a debugging help in a situation where a command like Insert acts upon an entity which was already despawned. When the command is applied it will panic with the message

thread 'main' panicked at 'Could not add a component (of type `alloc::string::String`) to entity 0v0 because it doesn't exist in this World.
If this command was added to a newly spawned entity, ensure that you have not despawned that entity within the same stage.
This may have occurred due to system order ambiguity, or if the spawning system has multiple command buffers

This tells which component (String) should have been added to which Entity (0v0) together with a hint that some system order dependency exist and is off.
To debug a situation like this one question would be "Which system was despawning this entity?" but this question might not be easy to answer.

A related issue and PR is

• Configurable error handling in commands #2004 and Command error handling #2241 but configurable error handling does not help in debugging the issue nor can it be easily be used in the case where the panicing system is a third party system

Solution

The panic message should contain the name of the system which despawned the entity, so when debugging I can immediately jump to this system, schedule it in a different stage or delay the despawn:

thread 'main' panicked at 'Could not add a component (of type `alloc::string::String`) to entity 0v0 because it doesn't exist in this World.
Entity was despawned in use_after_despawn::do_despawn.
If this command was added to a newly spawned entity, ensure that you have not despawned that entity within the same stage.
This may have occurred due to system order ambiguity, or if the spawning system has multiple command buffers'

In this case use_after_despawn::do_despawn is the fully qualified name of the system do_despawn.

The implementation extents Commands with a system name (if it is a static str).
When Despawn (or DespawnRecursive) is added to the queue the struct carries on this system name.
When Despawn::write is run, it is setting some crude system name state on the world.
When EntityRef::despawn is run, it looks up the system name from the world and adds this entity and this name to a World::despawned vec.
This vec is cleared at the beginning of every stage (ignoring use cases without stages).
When a panic happens due to a missing entity during a Command::write, you can now look up the entity in the World::despawned vec and put the system name in the panic message.

[payload]

I should just pass the Cow here 🐄 . It is in both cases cheap, right?

[payload]

Maybe it would be more appropriate to pass the whole SystemMeta, but well, I can't figure out the lifetime specifiers. And maybe the lifetime is not even guaranteed since the Despawn command, lands in a queue and the later the SystemMeta would land in some kind of buffer for the whole stage.

[payload]

This set name thing is crude. I am sorry. It may could be a separate despawn* function on world instead which takes the despawn origin name.

[alice-i-cecile]

Closing as #3851 was merged :)