Remove UseProvidedBody string matching from DelegateBodySyntaxExtractor

[Copilot]

DelegateBodySyntaxExtractor searched for lambdas by matching the string "UseProvidedBody" against method names in the syntax tree. This is fragile and unnecessary since BodyGenerationData.RuntimeDelegateBody already tells us whether a delegate body was provided.

Approach

Instead of string-matching a method name, use the data from BodyGenerationData to decide when to extract, and structural position to decide what to extract:

• FluentBodyResult — Added HasDelegateBody flag, set when RuntimeDelegateBody is non-null
• GeneratesMethodGenerationPipeline — Reversed the flow: execute the generator method first, then use HasDelegateBody to conditionally trigger syntax extraction
• DelegateBodySyntaxExtractor — Replaced descendant-node scan for "UseProvidedBody" with structural lookup: find the outermost InvocationExpressionSyntax in the method's return expression and extract its lambda argument

-InvocationExpressionSyntax? invocation = generatorMethodSyntax
-    .DescendantNodes()
-    .OfType<InvocationExpressionSyntax>()
-    .FirstOrDefault(inv =>
-        inv.Expression is MemberAccessExpressionSyntax memberAccess &&
-        memberAccess.Name.Identifier.Text == "UseProvidedBody");
+ExpressionSyntax? returnExpression = GetReturnExpression(generatorMethodSyntax);
+if (returnExpression is not InvocationExpressionSyntax invocation)
+    return null;

Pre-existing fix

Added missing WithCompileTimeConstants and Stage5 implementations in DataMethodBodyBuilders.cs to fix build errors on this branch.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Remove looking for body statement</issue_title>
<issue_description>In a previous PR, #94, a new way to create body was added: to copy the code defined in UseProvidedBody method to the target body.

I like how that works, but I don't like how that is implemented. In DelegateBodySyntaxExtractor, the code looks for memberAccess.Name.Identifier.Text == "UseProvidedBody" which is not very clean.

In BodyGenerationData record, the delegate defined in UseProvidedBody is already stored. Is that not enough to copy the source code? Maybe UseProvidedBody instead of taking Action/Func delegate, should take some "Expression" parameter, or something, so it can capture the exact code, which would remove the need to look for "UseProvidedBody" string?</issue_description>

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

• Fixes Remove looking for body statement #95

---

⚡ Quickly spin up Copilot coding agent tasks from anywhere on your macOS or Windows machine with Raycast.

[codecov]

Codecov Report

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

Files with missing lines	Patch %	Lines
....Generators/DataBuilding/DataMethodBodyBuilders.cs	0.00%	14 Missing ⚠️
...crementalGenerators/DelegateBodySyntaxExtractor.cs	0.00%	14 Missing ⚠️
...talGenerators/GeneratesMethodGenerationPipeline.cs	0.00%	13 Missing ⚠️
...crementalGenerators/BodyGenerationDataExtractor.cs	53.84%	4 Missing and 2 partials ⚠️

📢 Thoughts on this report? Let us know!

[Copilot]

Pull request overview

This PR removes fragile string-matching for detecting UseProvidedBody and instead uses BodyGenerationData.RuntimeDelegateBody to decide when to extract a delegate body, while updating syntax extraction to look at the generator method’s return expression structure.

Changes:

• Added HasDelegateBody to FluentBodyResult and populated it from BodyGenerationData.RuntimeDelegateBody.
• Reordered fluent-body generation flow to execute the generator method first, then conditionally run syntax extraction only when a delegate body was provided.
• Updated DelegateBodySyntaxExtractor to extract the lambda body from the outermost invocation in the generator method’s return expression (instead of scanning descendants for "UseProvidedBody"), and added missing fluent builder stages for compile-time constants.

Reviewed changes

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

Show a summary per file

File	Description
EasySourceGenerators.Generators/IncrementalGenerators/GeneratesMethodGenerationPipeline.cs	Switches fluent-body flow to runtime-execute first and then conditionally syntax-extract delegate bodies.
EasySourceGenerators.Generators/IncrementalGenerators/GeneratesMethodExecutionRuntime.cs	Extends FluentBodyResult to include HasDelegateBody.
EasySourceGenerators.Generators/IncrementalGenerators/DelegateBodySyntaxExtractor.cs	Changes extraction strategy to use the generator method’s return expression shape and adds GetReturnExpression.
EasySourceGenerators.Generators/IncrementalGenerators/BodyGenerationDataExtractor.cs	Sets HasDelegateBody based on presence of RuntimeDelegateBody.
EasySourceGenerators.Generators/DataBuilding/DataMethodBodyBuilders.cs	Adds missing WithCompileTimeConstants and Stage5 builder implementations.

---

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

[Copilot]

When HasDelegateBody is true but TryExtractDelegateBody returns null (e.g., non-lambda argument or unexpected return-expression shape), the code silently falls back to GenerateSimplePartialMethod. For parameterized delegates, ReturnValue will be null and the generated partial method will return default, which is incorrect and hard to diagnose. Consider reporting a diagnostic (and failing generation for that target) when HasDelegateBody is true but extraction fails, instead of falling back to the runtime-evaluated ReturnValue.

[Copilot]

GetReturnExpression’s comment says the method “assumes … at most one return statement”, but the implementation uses FirstOrDefault(), which will silently pick the first return if there are multiple. Consider enforcing the assumption (e.g., SingleOrDefault + diagnostic) or updating the comment/logic so unexpected shapes don’t lead to extracting the wrong expression without any signal.