Fix rename conflict detection for local functions and lambdas

[Copilot]

Summary

C# now allows variables in outer scopes to have the same name as variables in nested local functions and lambda expressions. This PR removes the incorrect conflict detection that was treating these valid renamings as conflicts.

Changes Made

• Understand the issue: C# now allows outer variables to have the same name as inner local function/lambda variables
• Locate the conflict checking code in LocalConflictVisitor.cs
• Build the solution to understand the structure
• Fix VisitLocalFunctionStatement to not track parameters but still visit bodies
• Fix VisitSimpleLambdaExpression to not track parameters but still visit bodies
• Fix VisitParenthesizedLambdaExpression to not track parameters but still visit bodies
• Update existing lambda tests to reflect new C# behavior (no conflicts expected)
• Add test cases for local functions (both static and non-static)
• Manual testing to verify C# compiler accepts the code
• Code review completed - no issues found
• Security check completed - no issues found
• Address failing tests
• Address reviewer feedback about visiting bodies

Technical Details

The root cause was that LocalConflictVisitor was tracking lambda parameters and local function parameters in the same scope as outer variables, causing false conflicts to be reported. The fix is to:

1. Not track lambda/local function parameters (avoiding cross-scope conflicts)
2. Still visit the body of lambdas/local functions (detecting intra-scope conflicts)

This ensures we detect legitimate conflicts within the lambda/local function scope while allowing shadowing of outer variables.

Test Results

• Updated lambda conflict tests to expect no conflicts
• Added local function test cases
• Build succeeded with no errors

The fix resolves the issue where renaming t to t1 incorrectly reported a conflict with a local function's variable t1.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>C# VS2022 Bug when trying to rename variables in local static functions.</issue_title>
<issue_description>This issue has been moved from a ticket on Developer Community.

---

The VS Rename Dialog reports an "unresolvable conflict" for duplicate var names.
This is logical correct for non-static local functions but not for static ones.
(The C# compiler accepts duplicate names in such configuration of course)

---

Original Comments

Feedback Bot on 4/11/2022, 03:02 AM:

(private comment, text removed)

---

Original Solutions

(no solutions)</issue_description>

<agent_instructions>@copilot C# has changed, so it is now legal for an outer variable to have the same name as a variable within a nested lambda or local function. However, rename views renaming such an outer variable to the same name as one of the inner local variables an unresolvable conflict, since it thinks it will always cause an error.

Can you find where this check is being done and remove it? We likely won't need to add tests. we'll need to update existing tests to print the new expected behavior (no longer reporting a conflict).

The original post is an image. If you can't understand it, here is the code the user starts with:

using System;

class C
{
    static void Main(string[] args)
    {
        int t = 0;

        void ALocalFunction()
        {
            int t1 = 0;
        }
    }
}

Then they rename the first local variable from t to t1. This used to not be allowed due to language rules about variables with the same name. But it was allowed later.</agent_instructions>

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

@CyrusNajmabadi We would take a small community pr for this.

Fixes #60728

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[CyrusNajmabadi]

@copilot the following tests are failing:

ConflictingLocalWithSimpleLambdaParameter
NoConflictingLocalWithStaticLocalFunctionParameter
ConflictingLocalWithParenthesizedLambdaParameter
NoConflictingLocalWithLocalFunctionLocal
NoConflictingLocalWithLocalFunctionParameter

[CyrusNajmabadi]

@copilot

is this actually doing the right thing? or is it now adding these identifiers as things that could potentially conflict?

Also, this seems to only be addressing parameters. not necessarily locals.

i would also expect to see changes to how lambdas are processed as they should also support the new c# semantics.

Note: Perhaps ti's ok to be adding/removing the identifiers as you have done. But when a conflict is found, we might want to see if it crosses a lambda boundary, and if so, not treat it as a conflict.

[Copilot]

You're right - the approach now visits the lambda/local function bodies to detect internal conflicts while not tracking their parameters to avoid false cross-scope conflicts. Updated in commit fec8a4e.

The key changes:

1. Lambda/local function parameters are not added to the tracker (prevents cross-scope conflicts)
2. Bodies are still visited (detects legitimate intra-scope conflicts)
3. This handles both parameters and locals inside the functions correctly

This addresses your concerns about detecting conflicts within the lambda/local function scope while allowing the new C# shadowing semantics.

[Copilot]

@copilot the following tests are failing:

ConflictingLocalWithSimpleLambdaParameter
...

Fixed in commit 8a5f19c. The issue was that the lambda and local function visit methods were still tracking identifiers in the same scope as outer variables. The fix is to not track lambda parameters or local function parameters at all, since C# now allows shadowing.