public sealed class VxmlGeneratorTurns every .vxml in a project into the C# partial class that builds it.
No guide page documents this yet — the page shows what the code says about itself.
Remarks
The build half of the markup channel. Vixen.Ui.Markup is the compiler — lexer, parser, binder, emitter — and this is what runs it: an IIncrementalGenerator over the .vxml files the build hands it as additional texts. Editing a file therefore changes a method body in the compilation, which is what dotnet watch turns into a metadata update and what Vixen.Ui.HotReload is waiting for on the other side.
⚠ A generator is judged by what it does not re-run. Every step here is keyed on values — paths, contents, namespaces — so editing a C# file re-runs nothing, and editing one .vxml re-parses that file alone. The pipeline never calls Collect(): batching every file into one array would make every edit invalidate every output, which is the usual way a generator ends up incremental in name only.
⚠ Syntax errors stop the emit; binding errors do not. A VXML1xxx means the tree is a guess made during recovery, and emitting from a guess produces C# that may not parse — which buries the one diagnostic the author needs under a page of noise about generated code they cannot see. A VXML2xxx means the tree is right and its meaning is wrong, so the class is still emitted: the type keeps existing, and the error count stays at the one real cause instead of one per use site across the project.
Fields and properties (2)
public const string ReadStepThe name of the step that reads a .vxml down to values.
public const string CompileStepThe name of the step that lexes, parses, binds and emits.
Methods (1)
public void Initialize(IncrementalGeneratorInitializationContext context)Called to initialize the generator and register generation steps via callbacks on the
Used by (2)
- HarnessVixen.Ui.Markup.Generators.Tests
- VxmlGeneratorTestsVixen.Ui.Markup.Generators.Tests