bevy_ecs: forward type_id in InfallibleSystemWrapper

[jakobhellermann]

similar to #12030

Objective

bevy_mod_debugdump uses the SystemTypeSet::system_type to look up constrains like (system_1, system_2.after(system_1)). For that it needs to find the type id in schedule.graph().systems()

Now with systems being wrapped in an InfallibleSystemWrapper this association was no longer possible.

Solution

By forwarding the type id in InfallibleSystemWrapper, bevy_mod_debugdump can resolve the dependencies as before, and the wrapper is an unnoticable implementation detail.

Testing

• cargo test -p bevy_ecs
  I'm not sure what exactly could break otherwise.

[SpecificProtagonist]

Suggested change

	fn type_id(&self) -> core::any::TypeId {
	/// Type id of the wrapped system.
	fn wrapped_type_id(&self) -> core::any::TypeId {

Let's not shadow <InfallibleSystemWrapper as Any>::type_id with a different meaning (previously using the same name was fine, as it always returned the same result).

[urben1680]

If we rename the method, I'd vote for system_type because not every System is a wrapper. It also aligns with SystemSet::system_type

[chescock]

Do you want to add a unit test that verifies that the type ids are the same, with a comment that bevy_mod_debugdump is relying on it? That could reduce the risk of it regressing again.

Alternately, I think Bevy is internally matching things up using System::default_system_sets() and IntoSystemSet::into_system_set(). I don't know whether it's feasible for you to use SystemSets instead of type ids, but if you can, then the fact that they're used internally should make them more reliable.

[hymm]

It's a little weird that type id won't return the actual type id, but I think this fix makes sense. The internal uses are just to identify apply_deffered systems and getting systems for system stepping. And I can't think of any ways this would mess things up for external consumers.

[jakobhellermann]

Alternately, I think Bevy is internally matching things up using System::default_system_sets() and IntoSystemSet::into_system_set(). I don't know whether it's feasible for you to use SystemSets instead of type ids, but if you can, then the fact that they're used internally should make them more reliable.

Oh nice, that works as well:

    fn system_of_system_type(&self, set: &dyn SystemSet) -> Option<NodeId> {
        self.graph.systems().find_map(|(id, system, _)| {
            let is_system_set = system.default_system_sets().iter().any(|s| s.0 == set);
            is_system_set.then_some(id)
        })
    }

In that case I don't need this PR at all and can release bevy_mod_debugdump with bevy 0.16.0. I can close this PR then, unless there are other reasons to want this.

[alice-i-cecile]

I can close this PR then, unless there are other reasons to want this.

I'd like to err in favor of exposing system metadata more easily: I think that this is a less convoluted and more robust mechanism.