Support block-bodied methods in [Projectable] attribute by Copilot · Pull Request #152 · koenbeuk/EntityFrameworkCore.Projectables

Copilot · 2026-02-14T11:26:53Z

Support "classic" methods (not expression-bodied) - Complete ✅

All Features Implemented + Code Review Fixes:

Fixes Applied (Per Code Review)

1. ✅ Empty Block Diagnostic

Issue: Empty blocks returned null without reporting diagnostic
Fix: Now reports EFP0003 diagnostic with clear message

2. ✅ Transitive Local Variable Inlining

Issue: var a = 1; var b = a + 2; return b; wasn't fully expanding
Fix: Local initializers now recursively expand previously defined locals
Test: Added BlockBodiedMethod_WithTransitiveLocalVariables test

3. ✅ Semantics Preservation Warning

Issue: Local variables used multiple times get duplicated, changing semantics
Fix: Generator now emits EFP0003 warning when a local is referenced >1 time
Note: Still produces correct results for pure expressions, but warns about potential issues

4. ✅ Nested Block Local Variable Scoping

Issue: Locals in nested blocks could leak into outer scopes
Fix: Added check to prevent local declarations inside nested blocks (if/switch/etc.)
Test: Added BlockBodiedMethod_LocalsInNestedBlock_ProducesDiagnostic test

5. ✅ Documentation Fix

Issue: Example showed implicit return that doesn't compile in C#
Fix: Updated to show explicit return statement (return null;)

Test Coverage:

✅ 96 generator tests (net8.0) - all passing
✅ 101 generator tests (net10.0) - all passing
✅ 76 functional tests (all frameworks) - all passing
✅ 22 unit tests - all passing
✅ Total: 197+ tests passing

Key Implementation Details:

Transitive Inlining:

When processing local declarations, initializers are expanded using ReplaceLocalVariables
This ensures var a = x; var b = a; stores fully expanded value for b
Chain depth is unlimited (transitive closure)

Multiple Usage Detection:

New LocalVariableReferenceCounter walker counts identifier references
Warns when any local is used >1 time before inlining
Helps developers identify potential semantic changes

Nested Block Protection:

Checks for LocalDeclarationStatementSyntax in nested BlockSyntax
Prevents scope leakage and variable shadowing issues
Reports clear diagnostic message

All feedback addressed and thoroughly tested!

Original prompt

This section details on the original issue you should resolve

<issue_title>Support "classic" methods (not expression-bodied)</issue_title>
<issue_description>I want to be able to transform methods decorated with [Projectable] that are not expression-bodied to expression trees, because it makes the code easier to understand, that a bunch of ternary operators.

Of course, only a subset of control statements will be supported (like no "new" statements, etc), but the Source Generator has to warn about it when generating source.</issue_description>

<agent_instructions>Make a proof of concept of this, with common examples and test cases</agent_instructions>

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

Fixes Support "classic" methods (not expression-bodied) #151

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

- Created BlockStatementConverter to transform block bodies to expressions - Added support for simple return statements - Added support for if-else statements (converted to ternary) - Added support for local variable declarations (inlined) - Added diagnostics for unsupported statements (EFP0003) - Added comprehensive test cases - Updated existing test that expected block methods to fail Co-authored-by: PhenX <42170+PhenX@users.noreply.github.com>

- Created 7 functional tests demonstrating EF Core SQL translation - Added comprehensive documentation explaining feature, limitations, and benefits - All 174 tests passing across all projects Co-authored-by: PhenX <42170+PhenX@users.noreply.github.com>

PhenX · 2026-02-14T11:55:04Z

@copilot add support for nested if else, and more complex conditions. support absence of else too.
Add support for switch cases and switch statements using existing transformation for this, if possible.

- Support if statements without else clause (uses default or fallback return) - Support switch statements (converted to nested conditionals) - Handle if { return x; } return y; pattern - Added 5 generator tests and 4 functional tests - Updated documentation with new features and SQL examples - All 182 tests passing (84 generator + 76 functional + 22 unit) Co-authored-by: PhenX <42170+PhenX@users.noreply.github.com>

Copilot · 2026-02-14T12:05:43Z

@copilot add support for nested if else, and more complex conditions. support absence of else too.
Add support for switch cases and switch statements using existing transformation for this, if possib...

Done! ✅ All requested features implemented in commit 7067bc2:

1. Nested if-else - Already supported, confirmed working
2. Complex conditions - Already supported, confirmed working
3. If without else - Now fully supported in 2 patterns:

Single if with implicit default return
If followed by explicit fallback return statement

4. Switch statements - Now supported with:

Simple case labels
Multiple case labels (OR'd together)
Default clause
Without default (uses default literal)
EF Core optimizes multiple cases to SQL IN clauses

Added 9 new tests (5 generator + 4 functional) demonstrating all features. All 182 tests passing.

- Rename test to better reflect implicit return pattern - Add clarifying comment about control flow in BlockStatementConverter - All tests still passing Co-authored-by: PhenX <42170+PhenX@users.noreply.github.com>

Copilot

Pull request overview

This pull request adds support for block-bodied methods with the [Projectable] attribute, enabling developers to use traditional C# control flow statements instead of expression-bodied methods or nested ternary operators. The source generator now transforms supported block statements (if/else, switch, local variables) into expression trees that can be translated to SQL by Entity Framework Core.

Changes:

Introduced BlockStatementConverter class to transform block statements into expression syntax
Updated ProjectableInterpreter to detect and route block-bodied methods through the new converter
Added EFP0003 diagnostic warning for unsupported statements in block-bodied methods
Comprehensive test coverage with 14 generator tests and 11 functional tests verifying correct SQL generation
Added detailed documentation in BlockBodiedMethods.md

Reviewed changes

Copilot reviewed 52 out of 52 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
src/EntityFrameworkCore.Projectables.Generator/BlockStatementConverter.cs	New converter class that transforms if/else, switch statements, and local variables into expression trees
src/EntityFrameworkCore.Projectables.Generator/ProjectableInterpreter.cs	Integration logic to detect block-bodied methods and route them to BlockStatementConverter
src/EntityFrameworkCore.Projectables.Generator/Diagnostics.cs	Added EFP0003 warning diagnostic for unsupported statements
src/EntityFrameworkCore.Projectables.Generator/AnalyzerReleases.Unshipped.md	Documentation of new EFP0003 diagnostic
tests/EntityFrameworkCore.Projectables.Generator.Tests/ProjectionExpressionGeneratorTests.cs	14 new generator tests covering various block-bodied patterns and one updated test
tests/EntityFrameworkCore.Projectables.Generator.Tests/*.verified.txt	Verified snapshots of generated code for each test case
tests/EntityFrameworkCore.Projectables.FunctionalTests/BlockBodiedMethodTests.cs	11 functional tests verifying SQL generation for different patterns
tests/EntityFrameworkCore.Projectables.FunctionalTests/*.verified.txt	Verified SQL output for multiple .NET versions
docs/BlockBodiedMethods.md	Comprehensive documentation with examples, limitations, and SQL output samples

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

src/EntityFrameworkCore.Projectables.Generator/BlockStatementConverter.cs

…tion # Conflicts: # tests/EntityFrameworkCore.Projectables.Generator.Tests/ProjectionExpressionGeneratorTests.cs

Copilot

Pull request overview

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

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

Copilot · 2026-02-15T09:13:53Z

src/EntityFrameworkCore.Projectables.Generator/BlockStatementConverter.cs

+        public ExpressionSyntax? TryConvertBlock(BlockSyntax block, string memberName)
+        {
+            if (block.Statements.Count == 0)
+            {
+                return null;
+            }
+


TryConvertBlock returns null for an empty block without reporting any diagnostic, but ProjectableInterpreter assumes the converter has already reported why conversion failed. This results in a silent failure for [Projectable] block-bodied methods like void Foo() { } (or malformed blocks) where no warning/error is emitted. Consider reporting UnsupportedStatementInBlockBody (or a dedicated diagnostic) when block.Statements.Count == 0, and include the member name in the message.

Copilot · 2026-02-15T09:13:53Z

src/EntityFrameworkCore.Projectables.Generator/BlockStatementConverter.cs

+            public override SyntaxNode? VisitIdentifierName(IdentifierNameSyntax node)
+            {
+                var identifier = node.Identifier.Text;
+                if (_localVariables.TryGetValue(identifier, out var replacement))
+                {
+                    // Replace the identifier with the expression it was initialized with
+                    return replacement.WithTriviaFrom(node);
+                }
+
+                return base.VisitIdentifierName(node);


Local variable inlining is not transitive: if a later local initializer references an earlier local (e.g., var a = ...; var b = a + 1; return b;), ReplaceLocalVariables will replace b with a + 1 but will not expand a, leaving an out-of-scope identifier in the generated expression. This happens because LocalVariableReplacer.VisitIdentifierName returns the replacement without visiting it. Consider either expanding locals when storing initializers (using already-known locals), or recursively visiting the replacement node (with cycle detection) so chained locals are fully inlined.

Copilot · 2026-02-15T09:13:53Z

src/EntityFrameworkCore.Projectables.Generator/BlockStatementConverter.cs

+            // First rewrite the return expression
+            var expression = (ExpressionSyntax)_expressionRewriter.Visit(returnStmt.Expression);
+
+            // Then replace any local variable references with their already-rewritten initializers
+            expression = ReplaceLocalVariables(expression);
+


Inlining locals by substituting their initializer expression can change semantics when the local is referenced multiple times, because the initializer is duplicated and re-evaluated each time (side effects / non-determinism / performance). This contradicts the PR description/documentation about preserving semantics. Consider restricting supported local initializers to side-effect-free expressions, emitting a diagnostic when a local is referenced more than once, or using a representation that preserves single evaluation (if feasible for EF translation).

Copilot · 2026-02-15T09:13:54Z

docs/BlockBodiedMethods.md

+### 6. If Statements Without Else (uses default value)
+```csharp
+[Projectable]
+public int? GetPremiumIfActive()
+{
+    if (IsActive)
+    {
+        return Value * 2;
+    }
+    // Implicitly returns null (default for int?)
+}


The GetPremiumIfActive example shows an implicit fall-through return (no final return), but this does not compile in C# (non-void methods must return on all paths). As written, users can’t actually use this pattern even if the generator can transform it in isolation. Consider updating the docs to show an explicit fallback (e.g., return null;) and/or clarify that the generator only runs on compilable code and that implicit returns are not a supported user pattern.

Copilot · 2026-02-15T09:13:54Z

src/EntityFrameworkCore.Projectables.Generator/BlockStatementConverter.cs

+                case SwitchStatementSyntax switchStmt:
+                    return TryConvertSwitchStatement(switchStmt, memberName);
+
+                case BlockSyntax blockStmt:


_localVariables is a single dictionary shared across the entire conversion, but TryConvertStatement allows nested BlockSyntax (e.g., inside if / switch) to be converted via TryConvertStatements, which in turn can process LocalDeclarationStatementSyntax. This means locals declared inside nested blocks can leak into outer scopes during replacement and can also collide with other locals, producing incorrect substitutions. Consider tracking locals with proper block scoping (push/pop per block) or disallow local declarations in nested blocks and report a diagnostic.

Suggested change

case BlockSyntax blockStmt:

case BlockSyntax blockStmt:

// Prevent locals declared in nested blocks from leaking into outer scopes

var nestedLocal = blockStmt.DescendantNodes()

.OfType<LocalDeclarationStatementSyntax>()

.FirstOrDefault();

if (nestedLocal is not null)

{

ReportUnsupportedStatement(nestedLocal, memberName, "Local declarations in nested blocks are not supported");

return null;

}

PhenX · 2026-02-15T09:27:05Z

@copilot apply suggested changes and adapt tests

- Add diagnostic for empty block bodies (EFP0003) - Fix transitive local variable inlining (var a = 1; var b = a + 2; now fully expands) - Add warning when local variables are used multiple times (semantics preservation) - Prevent locals in nested blocks from leaking into outer scopes - Fix documentation to show compilable C# code (no implicit returns) - Add tests for transitive locals and nested block restrictions - All 197 tests passing (96 net8.0 + 101 net10.0) Co-authored-by: PhenX <42170+PhenX@users.noreply.github.com>

Copilot · 2026-02-15T09:33:05Z

@copilot apply suggested changes and adapt tests

All code review suggestions applied in commit e2b1fad:

✅ Empty block diagnostic - Now reports EFP0003 when block is empty
✅ Transitive local inlining - var a = 1; var b = a + 2; now fully expands to 1 + 2
✅ Multiple usage warning - Warns (EFP0003) when locals are referenced >1 time (semantics preservation)
✅ Nested block locals - Prevents locals in if/switch blocks from leaking (reports diagnostic)
✅ Documentation fix - Replaced invalid implicit return with explicit return null;

Added 2 new tests verifying transitive inlining and nested block restrictions. All 197 tests passing.

Initial plan

ef840f6

Copilot AI assigned Copilot and PhenX Feb 14, 2026

Copilot started work on behalf of PhenX February 14, 2026 11:27 View session

Copilot AI and others added 2 commits February 14, 2026 11:36

Copilot AI changed the title ~~[WIP] Support transformation of classic methods to expression trees~~ Support block-bodied methods in [Projectable] attribute Feb 14, 2026

Copilot AI requested a review from PhenX February 14, 2026 11:45

Copilot finished work on behalf of PhenX February 14, 2026 11:45

Copilot started work on behalf of PhenX February 14, 2026 11:55 View session

Address code review feedback

75c638e

- Rename test to better reflect implicit return pattern - Add clarifying comment about control flow in BlockStatementConverter - All tests still passing Co-authored-by: PhenX <42170+PhenX@users.noreply.github.com>

Copilot finished work on behalf of PhenX February 14, 2026 12:09

PhenX requested a review from Copilot February 14, 2026 13:51

Copilot started reviewing on behalf of PhenX February 14, 2026 13:52 View session

Copilot AI reviewed Feb 14, 2026

View reviewed changes

Merge branch 'master' into copilot/support-classic-methods-transforma…

7a70fde

…tion # Conflicts: # tests/EntityFrameworkCore.Projectables.Generator.Tests/ProjectionExpressionGeneratorTests.cs

PhenX added this to the v6.0.0 milestone Feb 15, 2026

Remove unused code and add support for multiple early returns

06627c2

PhenX requested a review from Copilot February 15, 2026 09:04

Copilot started reviewing on behalf of PhenX February 15, 2026 09:05 View session

PhenX added 2 commits February 15, 2026 10:08

Missing verify files

9add2c9

Update docs

3c91bf9

Copilot AI reviewed Feb 15, 2026

View reviewed changes

Copilot started work on behalf of PhenX February 15, 2026 09:27 View session

Copilot finished work on behalf of PhenX February 15, 2026 09:33

-                case BlockSyntax blockStmt:
+                case BlockSyntax blockStmt:
+                    // Prevent locals declared in nested blocks from leaking into outer scopes
+                    var nestedLocal = blockStmt.DescendantNodes()
+                        .OfType<LocalDeclarationStatementSyntax>()
+                        .FirstOrDefault();
+                    if (nestedLocal is not null)
+                    {
+                        ReportUnsupportedStatement(nestedLocal, memberName, "Local declarations in nested blocks are not supported");
+                        return null;
+                    }

Conversation

Copilot AI commented Feb 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Support "classic" methods (not expression-bodied) - Complete ✅

All Features Implemented + Code Review Fixes:

Fixes Applied (Per Code Review)

1. ✅ Empty Block Diagnostic

2. ✅ Transitive Local Variable Inlining

3. ✅ Semantics Preservation Warning

4. ✅ Nested Block Local Variable Scoping

5. ✅ Documentation Fix

Test Coverage:

Key Implementation Details:

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

Uh oh!

PhenX commented Feb 14, 2026

Uh oh!

Copilot AI commented Feb 14, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Feb 15, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 15, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 15, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 15, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 15, 2026

Choose a reason for hiding this comment

Uh oh!

PhenX commented Feb 15, 2026

Uh oh!

Copilot AI commented Feb 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Copilot AI commented Feb 14, 2026 •

edited

Loading