Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[release/9.0-staging] Ignore modopts/modreqs for UnsafeAccessor field targets #109709

Conversation

github-actions[bot]
Copy link
Contributor

@github-actions github-actions bot commented Nov 11, 2024

Backport of #109694 to release/9.0-staging

/cc @AaronRobinsonMSFT

Customer Impact

  • Customer reported
  • Found internally

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.

class A
{
    private volatile int _i;
}

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

  • Yes
  • No

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.

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.
Copy link
Contributor

Tagging subscribers to this area: @dotnet/area-system-runtime-compilerservices
See info in area-owners.md if you want to be subscribed.

Copy link
Member

@jeffschwMSFT jeffschwMSFT left a comment

Choose a reason for hiding this comment

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

lgtm. we will take for consideration in 9.0.x

@Sergio0694
Copy link
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).

@AaronRobinsonMSFT AaronRobinsonMSFT added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels Nov 25, 2024
@AaronRobinsonMSFT
Copy link
Member

/ba-g "WASM timeouts not detected"

@AaronRobinsonMSFT AaronRobinsonMSFT merged commit 4b94961 into release/9.0-staging Nov 25, 2024
145 of 159 checks passed
@AaronRobinsonMSFT AaronRobinsonMSFT deleted the backport/pr-109694-to-release/9.0-staging branch November 25, 2024 23:57
@jeffschwMSFT jeffschwMSFT removed this from the 9.0.x milestone Nov 25, 2024
@jeffschwMSFT jeffschwMSFT added this to the 9.0.1 milestone Nov 25, 2024
@github-actions github-actions bot locked and limited conversation to collaborators Dec 26, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants