Switch generators to use data abstraction layer

[Copilot]

Generators now use DataGeneratorsFactory/DataMethodBodyBuilders/BodyGenerationData as the intermediate representation for both fluent and attribute-based patterns. SwitchCase attribute generation is commented out pending future replacement.

Execution runtime

• New ExecuteFluentBodyGeneratorMethod replaces ExecuteFluentGeneratorMethod — sets Generate.CurrentGenerator to a DataGeneratorsFactory, executes the user's fluent chain, then extracts BodyGenerationData from the resulting DataMethodBodyGenerator via reflection
• Invokes ReturnConstantValueFactory or RuntimeDelegateBody delegates to resolve constant return values at compile time
• Embedded resources updated from old RecordingGeneratorsFactory.cs → DataBuilding/DataGeneratorsFactory.cs, DataMethodBodyBuilders.cs, DataRecords.cs (with explicit using System; since execution compilations lack implicit usings)

Pipeline

• Fluent path routes through GenerateFromFluentBodyPattern → ExecuteFluentBodyGeneratorMethod → GenerateSimplePartialMethod (same output path as simple pattern)
• SwitchCase/SwitchDefault attribute path commented out

Example: fluent body generation now works end-to-end

public partial class MyClass
{
    public partial string GetGreeting();

    [MethodBodyGenerator(nameof(GetGreeting))]
    static IMethodBodyGenerator GetGreeting_Generator() =>
        Generate.MethodBody().ForMethod().WithReturnType<string>().WithNoParameters()
            .BodyReturningConstant(() => "Hello from fluent API");
}
// Generates: public partial string GetGreeting() { return "Hello from fluent API"; }

Tests

• Replaced MethodBodyBuilderTests, RecordingGeneratorsFactoryTests, MocksTests with DataMethodBodyBuilderTests and DataGeneratorsFactoryTests covering the full builder chain
• Added integration tests for fluent BodyReturningConstant (string, int)
• Commented out all SwitchCase/SwitchDefault tests and examples

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Switch Generators to use "data abstraction layer"</issue_title>
<issue_description>Fluent API Generators should now create a "Data" layer that states how the method should be implemented (see the new DataGeneratorsFactory and DataMethodBodyBuilders).

The non-fluent part, aka. the generators using attributes, should also rely on this abstraction layer.

Generators should build the method body based on the provided "Data" alone, regardless of how it was built. Extend the "Data" layer as needed.

Create tests for the data building layer if they build matching data.
Refactor and tests the code generators themselves, make sure they use the "data" layer as input.

• Focus on Body Generators, entire method generators (including name) are WIP and should be commented out if needed in this PR.
• Explicit SwitchCase statements will be replaced in the future, so comment out those as well (see DataMethodBodyBuilders.cs for details)</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Switch Generators to use "data abstraction layer" #86

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[codecov]

Codecov Report

❌ Patch coverage is 56.06061% with 29 lines in your changes missing coverage. Please review.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
...tors.Generators/GeneratesMethodExecutionRuntime.cs	48.93%	16 Missing and 8 partials ⚠️
...rs.Generators/GeneratesMethodGenerationPipeline.cs	73.68%	4 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

[Copilot]

Pull request overview

Refactors the method body generator to route fluent body generation through the new data abstraction layer (DataGeneratorsFactory → DataMethodBodyBuilders → BodyGenerationData) and disables the existing SwitchCase/SwitchDefault paths pending a future replacement.

Changes:

• Replaces the old RecordingGeneratorsFactory-based fluent execution with ExecuteFluentBodyGeneratorMethod, extracting BodyGenerationData via reflection.
• Updates generator execution compilation embedded resources to the DataBuilding sources.
• Reworks/introduces tests for the data-building chain and adds integration tests for fluent BodyReturningConstant; comments out SwitchCase/SwitchDefault examples/tests.

Reviewed changes

Copilot reviewed 22 out of 22 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
EasySourceGenerators.Generators/GeneratesMethodExecutionRuntime.cs	New fluent execution path that sets Generate.CurrentGenerator to DataGeneratorsFactory and extracts a constant return value from BodyGenerationData.
EasySourceGenerators.Generators/GeneratesMethodGenerationPipeline.cs	Routes fluent pattern through the new execution/runtime result and generates via the simple partial-method path; SwitchCase path removed.
EasySourceGenerators.Generators/EasySourceGenerators.Generators.csproj	Switches embedded resources from old builder/recording factory to DataBuilding sources.
EasySourceGenerators.Generators/DataBuilding/DataGeneratorsFactory.cs	New factory used by fluent API during execution compilation.
EasySourceGenerators.Generators/DataBuilding/DataMethodBodyBuilders.cs	New staged fluent builders producing DataMethodBodyGenerator + BodyGenerationData.
EasySourceGenerators.Generators/DataBuilding/DataRecords.cs	Adds using System; and defines BodyGenerationData record used as IR.
EasySourceGenerators.Generators/Consts.cs	Updates constants to reference DataBuilding types/property names.
EasySourceGenerators.GeneratorTests/MethodBodyBuilderTests.cs	Replaced with DataMethodBodyBuilderTests validating builder stages and resulting BodyGenerationData.
EasySourceGenerators.GeneratorTests/RecordingGeneratorsFactoryTests.cs	Replaced with DataGeneratorsFactoryTests validating factory entry points and full chain result type.
EasySourceGenerators.Tests/FluentBodyReturningConstantTests.cs	New integration tests validating runtime behavior and generated source for fluent constant bodies.
EasySourceGenerators.Tests/PiExampleTests.cs	SwitchCase/SwitchDefault tests commented out.
EasySourceGenerators.Tests/PiExampleFluentTests.cs	Fluent switch tests commented out.
EasySourceGenerators.Tests/BoolSwitchKeyTests.cs	SwitchCase/SwitchDefault tests commented out.
EasySourceGenerators.Tests/DefaultCaseThrowExpressionTests.cs	SwitchDefault tests commented out.
EasySourceGenerators.Tests/DefaultCaseConstValue.cs	SwitchDefault tests commented out.
EasySourceGenerators.Tests/DefaultCaseConstValueFluent.cs	Fluent switch tests commented out.
EasySourceGenerators.GeneratorTests/GeneratorDiagnosticsTests.cs	SwitchCase-related diagnostic tests commented out.
EasySourceGenerators.GeneratorTests/GeneratesMethodExecutionRuntimeTests.cs	Adds test coverage for ExecuteFluentBodyGeneratorMethod constant extraction; old fluent switch test commented out.
EasySourceGenerators.Generators/GeneratesMethodPatternSourceBuilder.cs	Switch generation helpers commented out pending replacement.
EasySourceGenerators.Generators/RecordingGeneratorsFactory.cs	Old implementation removed (file now only contains deprecation comments).
EasySourceGenerators.Examples/PiExample.cs	SwitchCase/SwitchDefault example commented out.
EasySourceGenerators.GeneratorTests/MocksTests.cs	Old fluent mock tests commented out (obsolete under new data layer).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

GenerateFromFluentBodyPattern proceeds as long as error == null, even if result.ReturnValue is null for a non-void partial method, which will generate return default; and hide failures to extract BodyGenerationData/constants. Consider validating that a concrete return value was extracted when !partialMethod.ReturnsVoid and reporting MSGH004 otherwise.

Suggested change

	return GeneratesMethodPatternSourceBuilder.GenerateSimplePartialMethod(
	containingType,
	partialMethod,
	result!.ReturnValue);
	if (!partialMethod.ReturnsVoid && (result is null || result.ReturnValue is null))
	{
	context.ReportDiagnostic(Diagnostic.Create(
	GeneratesMethodGeneratorDiagnostics.GeneratorMethodExecutionError,
	methodInfo.Syntax.GetLocation(),
	methodInfo.Symbol.Name,
	"Fluent body generator did not produce a return value for a non-void partial method."));
	return string.Empty;
	}
	return GeneratesMethodPatternSourceBuilder.GenerateSimplePartialMethod(
	containingType,
	partialMethod,
	result?.ReturnValue);

[Copilot]

With the SwitchCase/SwitchDefault branch removed, groups using those attributes will now fall through to the “simple pattern”/parameter validation path. That can emit misleading MSGH007 diagnostics (or generate a return default; body) instead of clearly stating that switch generation is currently disabled. Consider explicitly detecting SwitchCase/SwitchDefault usage and reporting a dedicated diagnostic (or MSGH004) that this pattern is not supported in this version.

[Copilot]

ExtractBodyGenerationData treats a non-DataMethodBodyGenerator return value as a successful execution and returns ReturnValue = null. This causes the pipeline to generate return default; for non-void partial methods, silently masking an unfinished/incorrect fluent chain. Consider returning an error (so MSGH004 is reported) when the result doesn't contain the expected Data property, or when required fields are missing for codegen.

[Copilot]

When RuntimeDelegateBody has parameters, the code returns ReturnValue = null and generation falls back to return default; with no diagnostic. That will produce incorrect behavior for any non-void partial method implemented via UseProvidedBody(x => ...). Prefer reporting a generator error (MSGH004) indicating that compile-time execution can't evaluate a runtime-parameterized delegate, or extend codegen to emit an invocation-based body instead of a constant/default.

Suggested change

	// For delegates with parameters, we can't invoke at compile time without values
	// For delegates with parameters, we can't invoke at compile time without values.
	// For void-returning methods this is acceptable (no return value is needed),
	// but for non-void methods we must not silently fall back to a default value.
	if (!isVoid)
	{
	throw new InvalidOperationException(
	"MSGH004: Compile-time execution cannot evaluate a runtime-parameterized delegate for a non-void method.");
	}

[Copilot]

constantValue?.ToString() relies on the current culture and type-specific ToString() implementations. For numeric types like double/decimal, this can emit non-C#-parsable strings in some locales (e.g., comma decimal separator), leading to invalid generated code. Consider formatting constants using invariant culture (e.g., IFormattable.ToString(null, CultureInfo.InvariantCulture)) and/or switching to a type-aware literal serializer rather than ToString().