Detecting system order ambiguities requires a specific world

[alice-i-cecile]

Problem

Detecting system order ambiguities should be entirely agnostic to the world that we're running on.

However, schedules (well, SystemStage for now) must be initialized on a specific World (taking &mut World) before we can check for ambiguities, or the whole thing panics.

Proposed solution

1. Clearly differentiate between "factual conflicts" and "hypothetical conflicts" on data access (Hypothetical and factual archetypes: unifying our data access checks #3119).
2. Ensure that the former requires a specific world, while the latter does not.
3. Compute system execution order ambiguities using only hypothetical conflicts.

Additional context

Discovered in #4299, as this makes exposing useful APIs and writing tests substantially harder than it should.

#1481 needs to take this design into account: we'll need to pass in the archetype invariants to the methods that compute hypothetical invariants

[maniwani]

(edited)
I agree that we shouldn't have to care, but components don't even exist until systems have been initialized on a World. AFAICT, we'd need a TypeId equivalent of FilteredAccessSet<ComponentId> to do it.

Also, if that isn't doable, this will be moot if we ever revive #2777.

[alice-i-cecile]

AFAICT, we'd need a TypeId equivalent of FilteredAccessSet to do it.

If we're looking for incremental solutions, we should be able to create a World within the ambiguity checking and initialize the systems there 🤔

I have a high-level vision of how I think this should work (#3119), but let me try this stopgap idea out.

[alice-i-cecile]

If we're looking for incremental solutions, we should be able to create a World within the ambiguity checking and initialize the systems there 🤔

Just tested this: it doesn't work. We can get ambiguity detection working without a World, but systems are fundamentally world-bound right now, along the lines of #2777.

Re-initializing systems on a different world fails silently, introducing UB via safe code, which then immediately crashes due to component storage misalignment.

I could probably get this working, but I really don't want to be mucking around more: this should just be handled correctly so we don't make the internals even scarier.