feat: combine the binding and attribute source generators by glennawatson · Pull Request #524 · reactiveui/ReactiveUI.SourceGenerators

glennawatson · 2026-10-26T01:38:53Z

Summary

Combines ReactiveUI.Binding.SourceGenerators into this repository, so the attribute generators and the binding generators build, test and ship together. The binding family's single-file generator structure is the model for both.

Both families share one SourceWriter and one array-backed EquatableArray<T>. Internal code uses arrays, lists and sets. ImmutableArray<T> stays only where Roslyn requires it.
The attribute generators lay out like the binding projects: one class and one models folder per generator, and one solution, solution filters and CI.
[IViewFor], [IViewFor<T>] and [IViewFor("TypeName")] are back, with the view registration the binding family reads.
Every shipped analyzer and diagnostic is kept, with its tests and a benchmark.
Every generator, analyzer and suppressor has a benchmark. The benchmark workflows run all of them.
Fixes found in the old repositories: a generic ReactiveObject owner now generates ToProperty; class is no longer repeated beside a class type constraint (CS0450); MAUI and Avalonia XAML in the 2009 namespace is read; an [ObservableAsProperty] value is readable from the notifications its helper raises as it starts.
The README is a short landing page with tables. The binding reference moved to docs, and each example has a README.

Why

The two families are coupled: the attribute generators write members the binding generators observe, and both replace the same ReactiveUI runtime work. Keeping them apart meant two sets of infrastructure and two sets of fixes.

Refs reactiveui/ReactiveUI.Binding.SourceGenerators#182, #184 and #185. Refs reactiveui/ReactiveUI#4538 and #4541.

Breaking changes

The ReactiveUI.Binding.SourceGenerators solution and project files are renamed into this repository's layout. Package IDs are unchanged.
The attribute packages and the ReactiveUI.Binding* packages keep separate version lines (v and binding-v tags), so tagging one family never moves the other.
ObservableAsPropertyHelper<T> gains Create overloads that take an ObservablePropertyTarget, and PendingValue. Existing overloads are unchanged.

How this was verified

Generator, analyzer and runtime tests for both families, including new tests for each fix above. The packed attribute package was inspected for its bands and README. The MAUI Android and wasm projects could not be built here because those workloads are not installed; CI builds them.

Notes for the reviewer

Start with src/ReactiveUI.SourceGenerators.Shared and CLAUDE.md, which describe the layout and the rules both families follow.
The history of the old repository is merged in, so the diff is large. The mechanical parts are the renames and the snapshot updates.

Checklist

I have read the Contribute guide
The PR title follows Conventional Commits
Tests cover this change, or the summary says why they do not
New or changed public API has XML documentation

Clean up the shared scenarios files

…#4) * Fix .NET Framework build errors and MAUI Visibility ambiguity - Add RequiresUnreferencedCodeAttribute polyfill for net462/net472/net481 targets where the attribute is inaccessible (only public in .NET 5+) - Add ModuleInitializerAttribute polyfill for benchmark net462 target - Fix CS0104 Visibility ambiguity in MAUI project on Windows targets by using type aliases instead of namespace imports * Fix remaining .NET Framework polyfill and visibility issues - Add InternalsVisibleTo from ReactiveUI.Binding to Wpf, WinForms, and Maui projects so they can access internal polyfill attributes (RequiresUnreferencedCodeAttribute, NotNullWhenAttribute, etc.) - Add missing using for POCOObservableForProperty in MAUI's DependencyObjectObservableForProperty.cs - Emit ModuleInitializerAttribute polyfill from source generator for consumer projects targeting .NET Framework (same pattern as existing CallerArgumentExpressionAttribute polyfill) * Remove all polyfill emission from source generator The generator should never emit polyfills into consumer projects. Instead it detects platform capabilities and generates appropriate code: - Remove CallerArgumentExpressionAttribute polyfill emission; the supportsCallerArgExpr flag now checks both C# 10+ language version AND that the attribute exists in the compilation, falling back to file/line dispatch when unavailable - Remove [ModuleInitializer] from generated registration code entirely - Replace [ModuleInitializer] in ReactiveUI benchmarks with explicit static constructor calls using an atomic bool guard pattern - Update snapshot tests