Repository navigation
[release/9.0-staging] Ignore modopts/modreqs for UnsafeAccessor field targets - #109709
Merged
AaronRobinsonMSFT merged 2 commits intoNov 25, 2024
Merged
AaronRobinsonMSFT merged 2 commits into
AaronRobinsonMSFT merged 2 commits into
Conversation
Copy link
Copy Markdown
Contributor
Sorry, something went wrong.
The generated IL remains correct and doesn't require a .volatile prefix for the generated accessor. This is based off of what Roslyn currently emits if a getter was available.
github-actions
Bot
requested review from
lambdageek and
thaystg
as code owners
November 11, 2024 21:17
Copy link
Copy Markdown
Contributor
|
Tagging subscribers to this area: @dotnet/area-system-runtime-compilerservices |
Sorry, something went wrong.
filipnavara
approved these changes
Nov 11, 2024
jkotas
approved these changes
Nov 11, 2024
This was referenced Nov 12, 2024
Open
Closed
Closed
steveisok
approved these changes
Nov 12, 2024
jeffschwMSFT
approved these changes
Nov 12, 2024
jeffschwMSFT
left a comment
Copy link
Copy Markdown
Member
There was a problem hiding this comment.
lgtm. we will take for consideration in 9.0.x
Sorry, something went wrong.
Copy link
Copy Markdown
Contributor
|
If it helps support this, this issue is also blocking ComputeSharp on .NET 9 when using primary constructors. I noticed it there because my CI runs started failing when I tried to bump the TFM of my samples to .NET 9 (see here). |
Sorry, something went wrong.
Copy link
Copy Markdown
Member
|
/ba-g "WASM timeouts not detected" |
Sorry, something went wrong.
AaronRobinsonMSFT
deleted the
backport/pr-109694-to-release/9.0-staging
branch
November 25, 2024 23:57
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.
Reviewers
6 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.
Backport of #109694 to release/9.0-staging
/cc @AaronRobinsonMSFT
Customer Impact
Customer reported issue: #109665. This was originally found in a MSBuild BinLog reader scenario. The specific issue is fields that are marked as volatile in C# aren't discoverable when using UnsafeAccessors and as such if someone writes the following, it is unable to be accessed.
This can't be discovered because the volatile in C# is embedded via a modreq and there is no place to describe that using the UnsafeAccessorAttribute.
The general issue is that when discovering the target field member, we currently require a complete match for fields. One could imagine we add some support for this, but given they are generally considered compiler directives, there is little value in considering them in this lookup scenario and so they should be ignored on fields. This is already done in the method case, but the relaxation was missed on field discovery.
Regression
Early in the .NET 9 release, the logic for signature comparrison was rewritten and regressed some unsupported issues and has uncovered a regression in a supported scenario.
Testing
Tests for the particular issue were added. I reached out to the Roslyn compiler team and verified the added test case is the only scenario where this occurs.
Risk
Low This is a permissive change on the way fields are looked-up and their types compared. Since C#/VB.NET don't provide other modopts/modreqs it is unlikely this will impact any other scenario.