Fix DebugInfo async local var number

[max-charlamb]

Bug when both an asyncContinuationArg and compTypeCtxtArg are present due to mutating value used for comparison.

There are four separate checks for special parameters which are hidden and decrement the actual var number. These are:

• Type context arg
• Vararg Handle
• Async Continuation
• Return buffer

Previously, the value would be decremented then compared in the order listed. This causes problems if multiple of these hidden parameters are present since the decremented value would be equal or lower to the hidden var number and would not be decremented.

Example - Async method with a hidden generic type context:

Both the type context and async continuation hidden vars are present:
info.compTypeCtxtArg = 1
and
lvaAsyncContinuationArg = 2

For varNum = 3:

1. varNum > info.compTypeCtxtArg -> 3 > 2 -> true and therefore varNum is decremented to 2
2. varNum > lvaAsyncContinuationArg -> 2 > 2 -> false and therefore varNum is not decremented.
3. The ILVarNum assigned is 2

For varNum = 4:

1. varNum > info.compTypeCtxtArg -> 4 > 2 -> true and therefore varNum is decremented to 3
2. varNum > lvaAsyncContinuationArg -> 3 > 2 -> true and therefore varNum is decremented to 2.
3. The ILVarNum assigned is also 2

This leads to two AsyncContinuationVarInfo both having VarNumber = 2

[Copilot]

Pull request overview

This PR fixes a critical bug in the JIT compiler's debug info generation where async methods with multiple hidden parameters (specifically async continuation and generic type context) would produce duplicate IL variable numbers.

Key Changes:

• Introduced originalVarNum to preserve the input value during hidden parameter processing
• Updated all four hidden parameter checks to use originalVarNum for comparisons instead of the mutating varNum

[jakobbotsch]

Thanks for finding this.

[dotnet-policy-service]

Tagging subscribers to this area: @steveisok, @dotnet/dotnet-diag
See info in area-owners.md if you want to be subscribed.