Improve warning for Send resources marked as non_send

[NiseVoid]

Objective

• Fixes unclear warning when insert_non_send_resource is called on a Send resource

Solution

• Add a message to the asssert statement that checks this

[github-actions]

Welcome, new contributor!

Please make sure you've read our contributing guide and we look forward to reviewing your pull request shortly ✨

[SkiFire13]

I already asked on Discord but nobody answered: this check only triggers if a resource is first inserted as non-Send and then as Send. If the order is swapped this won't trigger (there's even a test for this). IMO this is inconsistent, it should either always trigger or never.

[james7132]

It's perfectly safe to store a Send type in !Send storage, though probably a mistake to do so. We could fire a warning in the opposite case, but I'm against hard-failing when there's no safety issue.

[SkiFire13]

It's perfectly safe to store a Send type in !Send storage

It's also safe to store a Send type in Send storage though. The problem is that component_info is shared between Send and non-Send resources with the same TypeId. When a resource is inserted as both Send and non-Send then component_info.is_send_and_sync() will report only the value of the first one, which is however wrong for when the resource is first inserted as non-Send. This can be fixed by either:

• giving two different ComponentIds to Send and non-Send resources with the same TypeId
  • for example this could be done by duplicating Components::resource_indices for non-Send resources
  • in this case the given assertion would just become a sanity check and should never trigger in practice
• or making it a hard fail
  • this would essentially consist in making this assertion trigger in the opposite direction too, that is when a resource is inserted as Send first and then as non-Send
• or updating the component_info to set is_send_and_sync when it is false but a Send Resource is being inserted
  • this feels the worst option since it doesn't really fix the issue, it just hides it

At the end I would expect these two functions to either both succeed or both fail (currently only the first one succeeds):

#[derive(Resource)]
struct Foo;
fn send_then_non_send() {
    let mut world = World::new();
    world.insert_resource(Foo);
    world.insert_non_send_resource(Foo);
}
fn non_send_then_send() {
    let mut world = World::new();
    world.insert_non_send_resource(Foo);
    world.insert_resource(Foo);
}

[NiseVoid]

The case where I ran into this error is much simpler and simply requires insert_non_send_resource, then adding a system that uses it. Doing insert_resource first does prevent the error, which seems a bit odd but that doesn't really cause any usability problems

[james7132]

While this is a pretty big footgun as is, changing the behavior here would be a breaking change, and probably not suited for a PR aiming at 0.10.1. I'm OK with just changing the panic message for now, and have a separate PR resolve this for 0.11.

Hopefully we get !Send resources out of the World before then though.