CLI display goes crazy/blinking

[jcouv]

Describe the bug

In the middle of working, the CLI just started shaking uncontrollably. See sceren cap.
I tried a few things to stop it. Ended up hitting ESC a couple of times.

Note: the problem still occurs after I interrupted the agent. When I type into the chat input, the display appears to scroll or flicker.

Note: I solved the problem by using /exit and then resuming the session.

Affected version

GitHub Copilot CLI 1.0.2

Steps to reproduce the behavior

I do not know how to reproduce this.

I'll paste portion of the chat history below in case that has some clue:

❯ Good. Let's look at LocalFunction_42 next. What's the root cause of the problem? What are some options for fixing?

◐ Analyzing files and options

  I need to create a concise answer with a maximum of three sentences. My goal is to inspect relevant files to report intent with the tools available and possibly update my to-do list. I'll analyze the LocalFunction_42 root cause, looking into related tests and the code to
  ensure accuracy. It might be a good idea to utilize the explore agent and consider using the task explore for specific questions.

● Explore: Analyze LocalFunction_42
  ● Grep "GetSourceMethod" (q:\repos\roslyn2\src\ExpressionEvaluator\CSharp)
    └ 5 files found
  ● Read src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler\CompilationExtensions.cs lines 1-100
    └ 100 lines read

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Test\ExpressionCompiler\LocalFunctionTests.cs lines 2128-2180
  └ 53 lines read

● Root cause is two-part: in an async frame the EE binds against C.<F>d__0.MoveNext, but the local-function scope/map is recorded on the original source method C.F, so CompilationContext doesn’t discover G; and even if it did, the captured-closure instance for captured lives as
  a field on the state-machine this, not as a direct local/parameter, so the current hidden-argument lookup can’t supply it.
  That’s why non-capturing async local functions can work: they only need the method symbol, not closure/state-machine recovery.
  Best fix options are: (1) teach the EE to source local-function debug info from the original method when the current frame is a state machine, plus extend hidden-argument recovery to read display-class/state-machine fields from this; (2) push equivalent local-function info
  onto MoveNext in compiler/PDB emission; or (3) add a state-machine-specific path that reconstructs local functions/closure instances from hoisted-field metadata, with (1) being the most targeted EE-only approach.

❯ Is there any precedent that would inform choosing between these options?

◐ Investigating code precedents

  I need to find a concise answer in about three sentences. To do this, I'll inspect the relevant precedents in the codebase, using available tools. I probably need to search for existing handling related to currentSourceMethod, hoisted locals in the state machine, class
  variables, and previous patterns. Let's dig into this with rg/view to gather more insights!

● Grep "currentSourceMethod|GetSourceMethod\(|HoistedLocalScopeRecords|GetDisplayClassVariables|DisplayClassVariable|MoveNext" (Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler)
  └ 68 lines found

● Grep "StateMachineTypeName|GeneratedNameKind.StateMachineType|KickoffMethod|AsyncAndIterator|AwaitExpression" (Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler)
  └ 7 lines found

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler\EvaluationContext.cs lines 150-230
  └ 81 lines read

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler\CompilationContext.cs lines 110-180
  └ 70 lines read

◐ Evaluating precedent in options

  I need to determine if precedent informs how I choose options. It seems like I have enough information already. The `GetSourceMethod` and `currentSourceMethod` could serve as precedents for sourcing info from the original method, while the frame relies on the state machine. I
   should look at `GetDisplayClassVariables`, which has special handling for async `MoveNext` and traverses fields in the state machine. It might be valuable to inspect specific lines, such as 1505 and 1879.

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler\CompilationExtensions.cs lines 1-80
  └ 80 lines read

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler\CompilationContext.cs lines 1498-1525
  └ 28 lines read

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler\CompilationContext.cs lines 1874-1935
  └ 62 lines read

◐ Clarifying options for binding

  I'm looking to provide a concise answer in three sentences. I want to clearly mention that the precedent in the code opts for the original source method over MoveNext for handling bindings and hoisted locals. This precedent seems to favor the EE-only option 1, but I don't
  think mentioning compiler-side precedent is necessary here.

● Yes: the strongest precedent is that the EE already deliberately maps MoveNext back to the original source method for binding-related semantics via GetSourceMethod() and currentSourceMethod (CompilationExtensions.cs:31-49, EvaluationContext.cs:163-199), rather than requiring
  duplicated compiler/PDB data on the state-machine method. There’s also already special async-MoveNext handling for captured/display-class recovery in CompilationContext.GetDisplayClassVariables(...) (CompilationContext.cs:1505-1515), so the existing design bias is “teach the
  EE how to reinterpret state-machine frames,” not “change compiler emission.”
  So precedent favors the EE-only approach: source local-function scope info from the original method, then extend the existing state-machine/display-class recovery path so local-function rewriting can find the needed closure instance.

❯ Alright, let's do that

● Todo started: analyze-localfunction42

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler\Symbols\DisplayClassVariable.cs
  └ 224 lines read

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler\Symbols\EEMethodSymbol.cs lines 1-240
  └ 240 lines read

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler\CompilationContext.cs lines 1440-1835
  └ 371 lines read

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler\Rewriters\CapturedVariableRewriter.cs lines 1-220
  └ 136 lines read

● Compacting conversation history...

◐ Investigating implementation details

  I feel like we need to implement something based on the user’s suggestion. I should keep going with my inspection around GetDisplayClassVariables and local function debug information. It’s important to think through the necessary changes. I'll probably need to read the
  MethodDebugInfo APIs to get insights into the source method's debug information. I wonder how to map ilOffset? Maybe GetInScopeLocalFunctions deals with ilOffset differently than syntax? Time to inspect the implementation and search for more details.

○ Grep "GetInScopeLocalFunctions\(|LocalFunctions|LocalFunctionScopes" (Q:\repos\roslyn2\src)
  └ Timed out

○ Grep "GetInScopeHoistedLocalIndices\(|HoistedLocalScopeRecords" (Q:\repos\roslyn2\src)
  └ Timed out

✗ Read Q:\repos\roslyn2\src\ExpressionEvaluator\Core\Source\ExpressionCompiler\MethodDebugInfo.cs lines 1-260
  Path does not exist

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\Core\Source\ExpressionCompiler\PDB\MethodDebugInfo.cs lines 1-220
  └ 139 lines read

● Find local function scope implementation
  $ Get-Content C:\Users\jcouv\AppData\Local\Temp\copilot-tool-output-1773039365160-nco8ai.txt | Select-String -Pattern 'GetInScopeLocalFunctions|LocalFunctions' -Context 2,6
  └ 7 lines...

● Compaction completed. A new checkpoint has been added to your session.
  └ Use /session checkpoints 2 to view the compaction summary.

● Grep "struct LocalFunctionInfo|class LocalFunctionInfo" (Q:\repos\roslyn2\src)
  └ 1 line found

● Grep "new LocalFunctionInfo|LocalFunctionInfo\(" (Q:\repos\roslyn2\src)
  └ 2 lines found

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\Core\Source\ExpressionCompiler\PDB\LocalFunctionInfo.cs lines 1-120
  └ 40 lines read

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\Core\Source\ExpressionCompiler\PDB\MethodDebugInfo.Portable.cs lines 450-540
  └ 54 lines read

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler\EvaluationContext.cs lines 140-240
  └ 100 lines read

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler\CompilationContext.cs lines 120-240
  └ 121 lines read

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler\CompilationExtensions.cs lines 1-220
  └ 161 lines read

● Grep "GetLocalFunctionMethods\(|HiddenParameters|GetThisProxy\(|DisplayClassVariable" (Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler)
  └ 62 lines found

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler\Symbols\EELocalFunctionMethodSymbol.cs lines 1-280
  └ 225 lines read

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler\Rewriters\LocalFunctionCallRewriter.cs lines 1-260
  └ 206 lines read

◐ Evaluating class variables

  I need to check if the display class variables in EEMethodSymbol are accessible, but they might be internal. There could be a chance that LocalFunctionCallRewriter can use methods like eeMethod.GetDisplayClassVariable or even map the hidden parameter type. I think I should
  inspect any relevant methods and properties to get a clearer picture of how everything interacts. It feels like there’s a lot to uncover here!

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler\Symbols\DisplayClassVariable.cs lines 1-180
  └ 180 lines read

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler\Symbols\EEMethodSymbol.cs lines 1-240
  └ 240 lines read

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler\Rewriters\CapturedVariableRewriter.cs lines 1-200
  └ 136 lines read

◐ Verifying function invocation

  I need to find out how `LocalFunctionCallRewriter` is invoked. It seems like I might be able to pass `displayClassVariables` from `eeMethod` or from the context. I should do a search to clarify this further. Let’s see what information I can gather to get a better grasp on
  this situation! It might help streamline my understanding of the invocation process.

● Grep "LocalFunctionCallRewriter\.Rewrite\(" (Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp)
  └ 1 line found

● Grep "CapturedVariableRewriter\.Rewrite\(" (Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp)
  └ 1 line found

● Grep "_displayClassVariables|DisplayClassVariables" (Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler\Symbols\EEMethodSymbol.cs)
  └ 6 lines found

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler\Symbols\EEMethodSymbol.cs lines 620-690
  └ 71 lines read

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Test\ExpressionCompiler\LocalFunctionTests.cs lines 2120-2195
  └ 76 lines read

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler\CompilationContext.cs lines 1441-1838
  └ 370 lines read

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler\CompilationContext.cs lines 1398-1445
  └ 48 lines read

● Grep "currentSourceMethod|GetSourceMethod\(|MoveNext" (Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler)
  └ 17 lines found

● Grep "ReadMethodDebugInfo\(" (Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler)
  └ 1 line found

● Grep "CreateMethodContext\(" (Q:\repos\roslyn2\src\ExpressionEvaluator\VisualBasic\Source\ExpressionCompiler)
  └ 6 lines found

◐ Inspecting VB Approach

  I might need to take a closer look at the VB approach. It seems like it could be similar, but there aren't any local functions to consider. I wonder if using custom tokens would help with debugging information from the source method? To understand better, I should read
  through the CreateMethodContext for VB to see how it handles loading debug info for the source method. Let's see what I can find!

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\VisualBasic\Source\ExpressionCompiler\EvaluationContext.vb lines 143-230
  └ 88 lines read

◐ Evaluating function behavior

  I need to check if I should read the plan file for updates later. I want to inspect LocalFunction_42, as it seems there might be a placeholder success path failing with an Assert.Null error. It feels like I might be missing something there, so I'll need to implement a
  solution and test it out. I'll also look into the CompilationContext constructor to understand what data is being passed.

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler\CompilationContext.cs lines 1-140
  └ 139 lines read

◐ Understanding method context mapping

  I need to understand how CreateMethodContext utilizes the atLineNumber helper, especially in terms of methodToken and ilOffset corresponding to the real sequence point in MoveNext. It seems ReadMethodDebugInfo uses ilOffset primarily for determining import scopes, but not for
   local functions, which it reads in all local function scopes. To call GetInScopeLocalFunctions, I need the correct ilOffset. I'm wondering if there's a way to map MoveNext's ilOffset to the source method, perhaps by reusing method debug info span. I'll search for sequence
  point mapping utilities.

● Grep "GetSequencePoint|SequencePoint|Map.*ilOffset|GetMethodFromDocumentPosition|GetOffset" (Q:\repos\roslyn2\src\ExpressionEvaluator)
  └ 41 lines found

● Grep "ISymUnmanagedReader3|GetMethodFromDocumentPosition|GetOffset" (Q:\repos\roslyn2\src)
  └ 5 lines found

● Grep "GetMethodFromDocumentPosition|GetDocuments|GetSequencePoints" (Q:\repos\roslyn2\src\ExpressionEvaluator)
  └ 2 lines found

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\Core\Test\ExpressionCompiler\ExpressionCompilerTestHelpers.cs lines 720-770
  └ 51 lines read

✗ Grep "GetSequencePoints\(|ISymUnmanagedMethod" (Q:\repos\roslyn2\src\Compilers\Core\Portable\PEWriter\DebugDirectory)
  └ rg: Q:\repos\roslyn2\src\Compilers\Core\Portable\PEWriter\DebugDirectory: IO error for operation on Q:\repos\roslyn2\src\Compilers\Core\Portable\PEWriter\DebugDirectory: The system cannot find the file specified. (os error 2)

● Grep "GetSequencePoints\(" in **/*ISym*.cs (Q:\repos\roslyn2\src)
  └ No matches found

● Grep "GetDocumentsForMethod|FindClosestLine|GetSourceExtentInDocument|GetRanges" (Q:\repos\roslyn2\src)
  └ 22 lines found

● Grep "GetSequencePoints\(this|GetSequencePoints\(" in **/*.{cs,vb} (Q:\repos\roslyn2\src)
  └ 25 lines found

● Grep "SymUnmanagedMethodExtensions|ISymUnmanagedMethod.*SequencePoints" (Q:\repos\roslyn2\src)
  └ 1 line found

● Grep "GetSourceExtentInDocument|GetRanges\(|GetOffset\(|GetDocumentsForMethod|GetSequencePointCount" (Q:\repos\roslyn2\src\ExpressionEvaluator\Core\Source\ExpressionCompiler\PDB)
  └ 1 line found

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\Core\Source\ExpressionCompiler\PDB\MethodDebugInfo.Native.cs lines 1-240
  └ 240 lines read

◐ Considering portable reader debugging

  I’m thinking that the portable reader might benefit from custom debug info. It could be helpful to ask for the source method using a new token and check the mapped ilOffset, potentially starting at 0. I’ll need to look into inspecting ReadFromPortable, especially focusing on
  the sequence points. This could help clarify the debugging process!

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\Core\Source\ExpressionCompiler\PDB\MethodDebugInfo.Portable.cs lines 1-220
  └ 220 lines read

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\Core\Source\ExpressionCompiler\PDB\MethodDebugInfo.Portable.cs lines 220-360
  └ 141 lines read

● Grep "static .*GetSequencePoints\(|GetSequencePoints\(this ISymUnmanagedMethod" in **/*.{cs,vb} (Q:\repos\roslyn2\src)
  └ 1 line found

● Grep "ISymUnmanagedMethodExtensions" (Q:\repos\roslyn2\src)
  └ No matches found

◐ Inspecting function and managing tasks

  I'm looking into the shape for LocalFunction_42’s lowered method, and I'm wondering if it needs a state machine instance. I think I should compile and inspect the current error to see if the test is failing. Also, I guess I'll check on updating SQL todos—always important to
  track those. Since the user is asking for action, I’ll create todos for LocalFunction_42, possibly two, and check the existing ones too. Alright, let’s manage the todos now!

● Read ~\.copilot\session-state\edc769e6-b7f3-4938-8068-3c1c92001299\plan.md lines 1-120
  └ 11 lines read

◐ Inspecting test failures

  I see that tasks are already in progress, but I need to inspect the test failure baseline. I should consider running LocalFunction_42 first, maybe after building or testing. Before that, it makes sense to inspect the PDB or check if there are hidden parameters in the local
  function. I wonder if I could modify an existing test and focus on running it to see if there are any current failures.

● Run LocalFunction_42 test
  $ $env:DOTNET_CLI_WORKLOAD_UPDATE_NOTIFY_DISABLE=1; dotnet test src\ExpressionEvaluator\CSharp\Test\ExpressionCompiler\Microsoft.CodeAnalysis.CSharp.ExpressionCompiler.UnitTests.csproj --filter "FullyQualifiedName~LocalFunctionTests.LocalFunction_42" --nologo -v minimal
  └ 16 lines...

● Read shell output: Waiting up to 10 seconds for command output
  └ 16 lines...

◐ Considering testing methods

  I’m thinking that maybe the PowerShell output appears weird because of the build. I wonder if I should use a task agent for simpler tests instead? There’s also a chance it could be hanging due to a restore process. I’ll keep that in mind and plan to read further into this
  issue later to get more clarity on what's happening.

● Read shell output: Waiting up to 20 seconds for command output
  └ 20 lines...

◐ Investigating function behavior

  I'm thinking about whether the local function info from MoveNext is actually sourced from the method, and if the portable PDB can be read by GetSourceMethod. I need to verify this since the root cause might be different. It’s possible that the test needs to assert the actual
  IL and that code could already be fixed, though the summary claimed no changes for 42 yet. It seems we need to inspect test output for details. Maybe I can gather more context by running the test with no-build while looking into the IL.Inspecting method output

  I think I should start by inspecting the current methodData output since the test infrastructure might not be printing the IL. I need to search for the usage pattern of GetMethodData. Perhaps adding a test with VerifyIL could help after determining the expected IL through
  existing instrumentation. It seems like a straightforward approach to modify the test to include testData.GetMethodData("<>x.<>m0").VerifyIL("...") and then run it to capture the actual IL. Before I do that, I should check the current implementation to see if 42 seems to work
   because the locals in the current frame may relate to the state machine display class. It looks like an updated root cause analysis might be necessary, possibly indicating that no code change is needed, just a test. However, previous analysis noted that the local function
  map on the original method might be involved — could it pass because the breakpoint maps to the source method F instead of MoveNext?

● Read shell output: Waiting up to 1 second for command output
  └ 1 line...

● Grep "LocalFunction_42|GetMethodData\("<>x\.<>m0"\)" (Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Test\ExpressionCompiler\LocalFunctionTests.cs)
  └ 40 lines found

◐ Analyzing test implementation

  I think we should open a test around method 42 since we already have the lines. It could be useful to update or patch VerifyIL to check its output. It might be simpler to add a placeholder or to inspect the actual method IL instead.

  If the existing test passes, I might just do a minimal patch. However, I need to consider the PDB emission and local functions of the async method as that could help clarify my next steps. Ultimately, if the route is already supported, I need to rethink the root cause
  analysis.Verifying test implementation

  I need to verify by running the failing test with a placeholder. Creating a TODO to analyze or implement changes might suffice for now. After that, I can proceed with my planned update upon completion.

  Let’s review the repo diff to ensure everything is clean and check for any unrelated user changes. However, it seems our previous changes might be the only ones present. I should use git diff status to be careful about any unexpected issues and inspect the file state closely.

● Check git status
  $ git --no-pager status --short
  └ 1 line...

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Test\ExpressionCompiler\LocalFunctionTests.cs lines 2148-2182
  └ 34 lines read

● Edit Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Test\ExpressionCompiler\LocalFunctionTests.cs

● Run LocalFunction_42 for IL
  $ $env:DOTNET_CLI_WORKLOAD_UPDATE_NOTIFY_DISABLE=1; dotnet test src\ExpressionEvaluator\CSharp\Test\ExpressionCompiler\Microsoft.CodeAnalysis.CSharp.ExpressionCompiler.UnitTests.csproj --filter "FullyQualifiedName~LocalFunctionTests.LocalFunction_42" --nologo -v minimal
  └ 20 lines...

◐ I'm thinking about needing to inspect the output file. It's crucial to make sure everything is correct and nothing important is missing. I want to ensure that the information is clear and that it meets the necessary requirements. Checking for formatting, details, and any
  potential errors feels like a big task, but I'll approach it systematically. It’s all about catching things that could make a difference. Okay, let's go ahead and inspect that file carefully!

● Extract actual IL from failure
  $ Get-Content C:\Users\jcouv\AppData\Local\Temp\copilot-tool-output-1773039700924-13eaf3.txt | Select-String -Pattern 'Expected:|Actual:|IL_' -Context 3,20
  └ 128 lines...

● Extract LocalFunction_42 failure details
  $ Get-Content C:\Users\jcouv\AppData\Local\Temp\copilot-tool-output-1773039700924-13eaf3.txt | Select-String -Pattern 'LocalFunction_42' -Context 0,80
  └ 145 lines...

◐ I'm thinking about how to find any DisplayClassVariable where the DisplayClassInstance.Type matches the targetType. I want to get its instance bound expression directly instead of accessing the variable field. It seems like DisplayClassVariable exposes both
  DisplayClassInstance and fields, so maybe I'll need to add a method to produce the instance expression without those fields. I suspect there's an internal ToBoundExpression in DisplayClassInstance, so I should look further down the file and check the relevant classes,
  possibly nested in CompilationContext.

● Grep "class DisplayClassInstance|sealed class DisplayClassInstance|abstract class DisplayClassInstance" (Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler)
  └ 3 lines found

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler\CompilationContext.cs lines 1960-2085
  └ 83 lines read

● Grep "ToBoundExpression\(SyntaxNode syntax\)" (Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler)
  └ 4 lines found

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler\Symbols\DisplayClassInstance.cs lines 1-180
  └ 117 lines read

◐ I'm working through the specifics of how to handle DisplayClassVariable.Type for this proxy. I realize it might return variable.ToBoundExpression(syntax). I think there's a way for the helper to search through displayClassVariables.Values to check if variable.Type matches the
   targetType. This might just be the solution I need for this case, especially when considering captured locals. It's a bit tricky, but I feel like I'm on the right track!

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler\Symbols\EEMethodSymbol.cs lines 720-760
  └ 41 lines read

● Grep "GenerateThisReference\(|GetThisProxy\(|_displayClassVariables" (Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler\Symbols\EEMethodSymbol.cs)
  └ 6 lines found

◐ I'm identifying a potential risk with a non-capturing local function in an async state machine. It seems that the hidden parameters for that local function might end up being empty and not rewritten. That's a concern since it could lead to unexpected behavior. I’ll need to
  keep an eye on this to make sure everything functions as intended. I wonder if there are any solutions or best practices to mitigate this issue.

● Edit Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler\Symbols\EEMethodSymbol.cs

● Edit Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler\Rewriters\LocalFunctionCallRewriter.cs

● Run LocalFunction_42 after fix
  $ $env:DOTNET_CLI_WORKLOAD_UPDATE_NOTIFY_DISABLE=1; dotnet test src\ExpressionEvaluator\CSharp\Test\ExpressionCompiler\Microsoft.CodeAnalysis.CSharp.ExpressionCompiler.UnitTests.csproj --filter "FullyQualifiedName~LocalFunctionTests.LocalFunction_42" --nologo -v minimal
  └ 20 lines...

● Extract updated IL
  $ Get-Content C:\Users\jcouv\AppData\Local\Temp\copilot-tool-output-1773039817245-o08em5.txt | Select-String -Pattern 'Expected:|Actual:|IL_' -Context 3,24
  └ 141 lines...

◐ I'm pondering whether the binder resolved G to something else, possibly a method related to the current EE type, but that seems unlikely. I wonder if it could be sourcing a local function symbol from the source method instead of EELocalFunctionMethodSymbol. I'm thinking about
   searching the binder chain and including in-scope local functions. It might be worthwhile to inspect the CompilationContext's ExtendBinderChain specifically around local function methods and check for _inScopeLocalFunctions usage.

● Grep "_inScopeLocalFunctions|GetLocalFunctionMethods\(method\)|LocalFunction" (Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler\CompilationContext.cs)
  └ 14 lines found

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler\CompilationContext.cs lines 260-360
  └ 101 lines read

● Grep "class EELocalFunctionBinder" (Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler)
  └ 1 line found

✗ Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler\EELocalFunctionBinder.cs lines 1-220
  Path does not exist

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Source\ExpressionCompiler\Binders\EELocalFunctionBinder.cs lines 1-220
  └ 60 lines read

◐ Considering binding methods

  I’m thinking that maybe the method in the bound call isn't actually EELocalFunctionMethodSymbol, but rather a source local function symbol from the current source method. I wonder why the binder would choose that approach. It could be because the currentSourceMethod is the
  source F, and the binder's chain includes source locals or local functions from that method.

● Response was interrupted due to a server error. Retrying...

◐ Exploring compiled type IL

  I’m thinking about using the existing test infrastructure to inspect the compiled type IL. I could search for tests in the file and possibly use comp.VerifyTypeIL for the local function. It might be easier to use the compilation object to verify type IL in the test. To
  understand the issue, I need to inspect the type IL for source compilation around the local function. Maybe I could use existing compiled patterns for async local functions, like searching for "<F>g__G".

● Grep "async Task F\(|<F>d__|g__G" (Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Test\ExpressionCompiler\LocalFunctionTests.cs)
  └ 48 lines found

● Grep "VerifyTypeIL\(|<F>g__G|MoveNext" (Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Test\ExpressionCompiler)
  └ 5 lines found

◐ I'm thinking about inspecting nearby tests related to 764 and possibly looking into async local functions. I feel like I need to read around those lines to gather more context. It seems like there could be valuable information there, so I'll take my time to examine those
  tests closely. Okay, I'll make sure to explore this thoroughly before drawing any conclusions. I want to ensure I'm covering all my bases!

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Test\ExpressionCompiler\LocalFunctionTests.cs lines 740-860
  └ 121 lines read

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Test\ExpressionCompiler\LocalFunctionTests.cs lines 1528-1542
  └ 15 lines read

○ Grep "<F>g__G\|0_0\(ref C\.<F>d__0\)|<F>g__G\|0_\d+\(ref C\.<F>d__0\)|<F>g__G\|0_\d+\(ref valuetype C/'<>c__DisplayClass" (Q:\repos\roslyn2\src)
  └ Timed out

○ Grep "<F>g__G\|.*<F>d__0|<F>d__0.*g__G" (Q:\repos\roslyn2\src)
  └ Timed out

◐ Inspecting async local function tests

  I'm thinking I should look into the existing tests within the compiler repository, specifically focusing on async local function capture shapes. I'll search the CSharp tests for method names like g__G and keywords such as displayclass or state machine. To streamline this
  process, I plan to use a limited search (rg) that targets only the compiler tests. That should help me gather relevant information more efficiently!

● Grep "g__G\|.*DisplayClass|g__G\|.*d__0|MoveNext.*g__G|async.*local function" (Q:\repos\roslyn2\src\Compilers\CSharp\Test)
  └ 2 lines found

● Read Q:\repos\roslyn2\src\Compilers\CSharp\Test\Emit2\PDB\PDBLocalFunctionTests.cs lines 620-690
  └ 71 lines read

● Grep "async.*G\(|await.*G\(|DisplayClass0_0" (Q:\repos\roslyn2\src\Compilers\CSharp\Test\Emit2\PDB\PDBLocalFunctionTests.cs)
  └ 4 lines found

◐ Exploring compiler tests

  I think I need to consider implementing search async capture in some compiler tests, but maybe not in the PDBLocalFunctionTests. It might be better to use a narrower regex, perhaps looking into the CSharp Test/Emit* for occurrences of "await Task.Yield" close to g__G. This
  could help streamline my testing process and ensure I’m capturing the right scenarios. It feels like there's a clear path forward there!

● Grep "await .*Yield\(|async .*Task .*\{|g__G\|0_0\(ref .*d__|g__G\|0_0\(ref .*DisplayClass" (Q:\repos\roslyn2\src\Compilers\CSharp\Test)
  └ 5 lines found

◐ Refining search approach

  I'm realizing the initial scope is too broad. I should use more specific identifiers like "PDBLocalFunctionTests" or "CodeGenClosureTests" to narrow it down. It might help to search for the exact source snippet too, which could lead me to more relevant information. Focusing
  on those terms should provide clearer results and streamline my search. I'm curious to see how much that helps!

● Grep "int captured = 10;[\s\S]*int G\(\)" (Q:\repos\roslyn2\src\Compilers\CSharp\Test)
  └ No matches found

● Grep "int G\(\) \{ return captured \+ 1; \}" (Q:\repos\roslyn2\src\Compilers\CSharp\Test)
  └ No matches found

◐ Considering IL inspection options

  I’m thinking about the easiest way to inspect IL directly. Maybe I can use a small helper to compile source with Roslyn tests. It’s tricky, but I could check the emitted DLL using ildasm. Alternatively, I might build a quick C# program with csc, but I'm uncertain about the
  environment setup. Perhaps it’s simpler to use an existing function to verify the IL and test the output, which may match the expected IL for the user’s request about fixing branch enabling invocation.Exploring VerifyTypeIL usage

  I’m considering how to simplify the EE test. Maybe I should call `comp.VerifyTypeIL("C.<F>d__0", "...")` or just `comp.VerifyTypeIL("C", "...")`. The output should help me see the lowered method name, and I can use a placeholder to capture it. Adding `comp.VerifyTypeIL("C",
  """{ }""")` might be too vague, so I think focusing on the specific type `C.<F>d__0` could be better. I’ll need to search for usage around 1989 and inspect a snippet using VerifyTypeIL.

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Test\ExpressionCompiler\LocalFunctionTests.cs lines 1978-2032
  └ 55 lines read

● Grep "VerifyTypeIL\(" (Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Test\ExpressionCompiler\LocalFunctionTests.cs)
  └ 2 lines found

● Read Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Test\ExpressionCompiler\LocalFunctionTests.cs lines 2304-2380
  └ 77 lines read

● Grep "VerifyTypeIL\(".*d__" (Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Test\ExpressionCompiler)
  └ No matches found

● Grep "VerifyTypeIL\(".*<>c__DisplayClass" (Q:\repos\roslyn2\src\ExpressionEvaluator\CSharp\Test\ExpressionCompiler)
  └ No matches found

● Grep "VerifyTypeIL\(".*<.*d__" (Q:\repos\roslyn2\src\Compilers\CSharp\Test)
  └ No matches found

● Grep "VerifyTypeIL\(".*\+" (Q:\repos\roslyn2\src\Compilers\CSharp\Test)
  └ No matches found

◐ Hmm, I’m contemplating the issue with the hidden parameter type not being found while the helper seems fixed but no changes appear. It could be that HiddenParameters is empty. If the underlying method is static and only has visible parameters, maybe the async local function
  gets treated as an instance method on the state machine type, which would mean it has no hidden parameters. I need to keep digging into this — there's definitely a bit to figure out! Evaluating code review insights

  I’m exploring the code review subagent. There might be a way to inspect the bound tree, but I’m uncertain about that. I think the root cause could be tied to how local function info is handled in the current frame compared to the source method. It's interesting that the local
   functions from MoveNext show in the method data. I wonder if using local function info can help the binder adjust correctly. Exploring local functions and debug info

  I’m considering whether the custom debug info for MoveNext could store a loweredMethodToken for the generated proxy method G(). It seems there might actually be a synthetic method named G() in the state machine type, which could make calling "G()" valid. However, the root
  cause originally identified could be related to hidden args or state machine field paths. I think I should inspect the compiler tests or look for specific metadata names in the local function map concerning async captures. Let's narrow down those search patterns!

● Grep "<F>d__0.*g__G|g__G\|.*<F>d__0|DisplayClass0_0" (Q:\repos\roslyn2\src\Compilers\CSharp\Test\Emit\CodeGen)
  └ 5 lines found

● Grep "<F>d__0.*g__G|g__G\|.*<F>d__0|DisplayClass0_0" (Q:\repos\roslyn2\src\Compilers\CSharp\Test\Emit2)
  └ 5 lines found

◐ Searching for LocalFunction

  I need to search for the exact `<F>d__0` in the LocalStateTracingTests, as that might be helpful. Narrowing it down around "LocalFunction" could be a good direction. I might use `rg` on CodeGen*, but it seems like it could be easier to use selective grep in the saved file for
   "LocalFunction." I'll need to inspect the saved file to check out the matches. Let's see what we find!

● Filter emit2 async search results
  $ Get-Content C:\Users\jcouv\AppData\Local\Temp\copilot-tool-output-1773040031332-nzgvqz.txt | Select-String -Pattern 'LocalFunction|g__G|<F>d__0' -Context 1,4
  └ 22 lines...

● Filter codegen async search results
  $ Get-Content C:\Users\jcouv\AppData\Local\Temp\copilot-tool-output-1773040031341-9qktww.txt | Select-String -Pattern 'LocalFunction|g__G|<F>d__0' -Context 1,4
  └ 43 lines...

● Grep "captured|Task\.Yield\(|int G\(\)" (Q:\repos\roslyn2\src\Compilers\CSharp\Test\Emit\CodeGen\CodeGenAsyncTests.cs)
  └ 36 lines found

✗ Grep "captured|Task\.Yield\(|int G\(\)" (Q:\repos\roslyn2\src\Compilers\CSharp\Test\Emit2\Emit\CodeGenAsyncTests.cs)
  └ rg: Q:\repos\roslyn2\src\Compilers\CSharp\Test\Emit2\Emit\CodeGenAsyncTests.cs: IO error for operation on Q:\repos\roslyn2\src\Compilers\CSharp\Test\Emit2\Emit\CodeGenAsyncTests.cs: The system cannot find the file specified. (os error 2)

◐ Exploring file lines

  I'm thinking about narrowing down my search to interesting lines around 7963 in the file. Maybe I should focus on local functions related to that line. It seems like a good idea to hone in on this specific area. I should look through the file around that number to see if
  there are any relevant insights or connections. Let’s see what I can find!

● Read Q:\repos\roslyn2\src\Compilers\CSharp\Test\Emit\CodeGen\CodeGenAsyncTests.cs lines 7940-8075
  └ 136 lines read

◐ Searching for code elements

  I'm considering whether I can find something directly related. It might be useful to look into `symbolValidator` from the compiler. I also want to search for a local function like `async capture shapes` in `CodeGenLocalFunctionTests`. It seems like checking for `Task.Yield`
  in relation to local function might be a good direction to explore. There’s a lot to consider here, so I’ll go deeper in my search!

● Grep "Task\.Yield\(|await .*Yield\(" (Q:\repos\roslyn2\src\Compilers\CSharp\Test\Emit\CodeGen\CodeGenLocalFunctionTests.cs)
  └ 1 line found

● Operation cancelled by user

Expected behavior

No response

Additional context

-OS: Windows x64
-Terminal: Terminal
-Shell: pwsh

[csvan]

Can confirm this on OSX (iterm2 terminal) on version 1.0.2. There does not seem to be any clear pattern what triggers this - I will have workflows running for hours before it goes crazy, other times it happens after the first prompt.

[devm33]

Hi @jcouv and @csvan we have a new rendering approach available under --alt-screen (will be persisted in config after the first run) that fixes this problem. Please give it a try, happy to get any feedback as we roll it out!

[danieldekay]

Can confirm this happens in MacOS in iTerm2, Ghostty.