[clr-interp] Fix Runtime_74635_1 test#122194
Merged
janvorli merged 2 commits intodotnet:mainfrom Dec 5, 2025
Merged
Conversation
This is an interesting test which touches on a poorly design/documented portion of the ECMA spec. Notably, what can be done with the this pointer of a structure during its construction. Notably, if the this pointer is stored somewhere else, and then that pointer is used then there is a possibility of mutating a value on the IL evaluation stack in the current interpreter implementation. As that is not considered a thing which should be possible, RyuJIT has the policy of creating function local temporaries for the newobj instruction, and then copying the result to a location on the evaluation stack. This change matches that behavior which is the current reading of the correct behavior according to the ECMA standard.
Contributor
|
Tagging subscribers to this area: @BrzVlad, @janvorli, @kg |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes the Runtime_74635_1 test by ensuring ECMA spec compliance for value type construction in the interpreter. The issue occurs when a value type constructor exposes its this pointer (e.g., by storing it in a closure), which could allow external mutation of values on the evaluation stack. The fix matches RyuJIT behavior by allocating value type instances in stable memory during construction, then copying the result to the evaluation stack afterward.
Key Changes
- Introduces a flag
resultIsNewObjToVTWithCopyto track when value typenewobjrequires a copy operation - Allocates
newobjvalue type instances as global variables (stable memory) during construction - Adds post-constructor logic to copy the initialized value type from the temporary to a new stack location
This was referenced Dec 5, 2025
Open
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
This is an interesting test which touches on a poorly design/documented portion of the ECMA spec. Notably, what can be done with the this pointer of a structure during its construction. Notably, if the this pointer is stored somewhere else, and then that pointer is used then there is a possibility of mutating a value on the IL evaluation stack in the current interpreter implementation. As that is not considered a thing which should be possible, RyuJIT has the policy of creating function local temporaries for the newobj instruction, and then copying the result to a location on the evaluation stack. This change matches that behavior which is the current reading of the correct behavior according to the ECMA standard.