Skip to content

Conversation

@jjonescz
Copy link
Member

@jjonescz jjonescz commented Oct 10, 2025

Fixes #79054.
Closes #73549.

@jjonescz jjonescz marked this pull request as ready for review October 10, 2025 13:44
@jjonescz jjonescz requested a review from a team as a code owner October 10, 2025 13:44
@AlekseyTs
Copy link
Contributor

AlekseyTs commented Oct 10, 2025

Briefly glanced over changes (commit 2), not a complete review pass #Closed

@jjonescz jjonescz requested a review from AlekseyTs October 13, 2025 18:47
@jjonescz
Copy link
Member Author

@AlekseyTs @dotnet/roslyn-compiler for reviews, thanks

Copy link
Contributor

@AlekseyTs AlekseyTs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM (commit 4), but I recommend getting a sign-off from ref-safety experts.

@jjonescz jjonescz requested a review from a team October 23, 2025 09:15
@jjonescz
Copy link
Member Author

@dotnet/roslyn-compiler for reviews, thanks

@RikkiGibson RikkiGibson self-requested a review October 30, 2025 18:50
Copy link
Member

@RikkiGibson RikkiGibson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I agree that the change being made here is correct, in the sense that it doesn't open any ref safety holes, and removes ref safety errors which were "unnecessary".

It also looks like this decision is a reversal of ref safety changes made in #24904, which were themselves a reversal of a prior state where the ref-safe-context of an assignment was the RHS.

In my view this emphasizes that this area needs to be well-specified. Basically I am OK with letting this PR in as it is now, but, let's make sure that before too long we get the behavior we actually want recorded in the standard. I would be happy to work together on this.

@jjonescz
Copy link
Member Author

It also looks like this decision is a reversal of ref safety changes made in #24904, which were themselves a reversal of a prior state where the ref-safe-context of an assignment was the RHS.

Interesting find, thanks.

Note that there are already some places where RHS is used, it's just not very consistent. For example:

return GetValEscape(((BoundAssignmentOperator)expr).Right, localScopeDepth);

In my view this emphasizes that this area needs to be well-specified. Basically I am OK with letting this PR in as it is now, but, let's make sure that before too long we get the behavior we actually want recorded in the standard. I would be happy to work together on this.

The standard has this section, but it doesn't seem to answer what the safe-context should be for assignment operators I think:

16.4.15.5 Operators

The application of a user-defined operator is treated as a method invocation (§16.4.15.6).

For an operator that yields a value, such as e1 + e2 or c ? e1 : e2, the safe-context of the result is the narrowest context among the safe-contexts of the operands of the operator. As a consequence, for a unary operator that yields a value, such as +e, the safe-context of the result is the safe-context of the operand.

Note: The first operand of a conditional operator is a bool, so its safe-context is caller-context. It follows that the resulting safe-context is the narrowest safe-context of the second and third operand. end note

Filed dotnet/csharpstandard#1444

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Unexpected ref safety error in an assignment A test gap in GetValEscape method

3 participants