Fix #3860: Avoid 'out var' if the variable recurs in the argument list#3864
Open
siegfriedpammer wants to merge 2 commits into
Open
Fix #3860: Avoid 'out var' if the variable recurs in the argument list#3864siegfriedpammer wants to merge 2 commits into
siegfriedpammer wants to merge 2 commits into
Conversation
Passing the same local as multiple out arguments of one call made DeclareVariables turn the first use into an implicitly-typed declaration, producing 'f(out var x, out x)'. Referencing an implicitly-typed out variable in another argument of the declaring call is rejected by the compiler (CS8196), because its type is only inferred once overload resolution of that call has completed. The explicitly-typed form 'f(out int x, out x)' is valid, so fall back to the explicit type in that case. Assisted-by: Claude:claude-fable-5:Claude Code
siegfriedpammer
force-pushed
the
fix-3860-outvar-explicit-type
branch
from
a7088b2 to
7ccb8f4
Compare
Member
|
Do we also need to worry about nested cases? |
CS8196 also fires when the second reference sits inside a nested call in another argument of the declaring call, e.g. OutAndValue(out var a, UseAndReturn(out a)). The existing check already covers this because it walks all descendants of the sibling arguments; this fixture pins that behavior. Assisted-by: Claude:claude-fable-5:Claude Code
siegfriedpammer
force-pushed
the
fix-3860-outvar-explicit-type
branch
from
1104b22 to
62c8d3b
Compare
Member
Author
|
I added a test case, seems Claude implemented support for it "by accident"... the weird first-child-next-sibling loop traverses all descendants of the individual arguments... I was thinking about changing the loop to actually use InvocationExpression.Arguments instead... what do you think? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #3860.
When the same local is passed as multiple out arguments of one call, DeclareVariables turned the first use into an implicitly-typed declaration, producing
f(out var x, out x), which fails to recompile with CS8196: referencing an implicitly-typed out variable in another argument of the declaring call is not permitted, because its type is only inferred once overload resolution of that call has completed. The explicitly-typed formf(out int x, out x)is valid C#, so the transform now falls back to the explicit type when the variable is referenced again within the declaring call (resolving identifiers through collision-merged variables).New Pretty fixture methods in
OutVariables.csreproduce the issue (previously decompiled asout var a, out ain all compiler configurations); full Pretty/Ugly/ILPretty/VBPretty runs pass.This PR was authored by an AI agent on behalf of @siegfriedpammer.
🤖 Generated with Claude Code