SystemAccessInferenceGenerator

Remarks

[04](../../docs/plan/04-ecs-and-scripting.md) § Layer 2 asks for this and names what it must emit into: IDeclaredAccess, not [Reads]/[Writes]. The reason is that SystemAccess.Declare().Write<Position>() closes a generic and therefore assigns Position a component id, where an attribute names a System.Type and can only look one up — and there is nothing to look up until something in the process has stored one.

⚠ Emitting a declaration nothing reads would be worse than emitting none. SystemGraph.Build prefers IDeclaredAccess over the attributes, and SystemRunner hands the same object to the job scheduler's safety system — so what is inferred here decides both the frame's parallelism and what the race detector believes. That is why it is opt-in: a wrong inference is a data race, and a class that has asked for one is a class whose author says its access is visible in its own body.

⚠ The delegate and visitor forms cannot say read from write, so they are read as writes. QueryAction<T0, T1> takes every component by ref whether or not the body assigns through one, so there is no signal to read. Over-declaring costs parallelism and under-declaring is a race, so the direction is chosen and written down rather than guessed at per call. The chunk form is exact, because Values<T> and ReadValues<T> are different calls — which is the same distinction Get and Read make on the world.

Here rather than in Vixen.Ecs.Generators. That project is referenced by Vixen.Ecs and travels in no package, because its output does not depend on the compilation and a second referencing assembly would emit a second copy of it. This one has to run in a game's own compilation, which is what this assembly is packed for.

Methods (1)

• public void Initialize(IncrementalGeneratorInitializationContext context)

  Called to initialize the generator and register generation steps via callbacks on the

Used by (1)

• SystemAccessInferenceTestsVixen.Engine.Generators.Tests