Skip to content

Conversation

@DustinCampbell
Copy link
Member

@DustinCampbell DustinCampbell commented Apr 23, 2025

Fixes #77951

Field access in auto-properties mostly already worked in EnC.

  • Update the EnC unit testing infrastructure to always run C# tests with the "preview" language version and VB tests with the "latest" language version.
  • Add unit test coverage
  • Fix small issue in the AbstractEditAndContinueAnalyzer to allow auto-properties to be detected from a set accessor.

cc @tmat

@DustinCampbell DustinCampbell requested a review from a team as a code owner April 23, 2025 23:37
@ghost ghost added Area-Interactive untriaged Issues and PRs which have not yet been triaged by a lead labels Apr 23, 2025
"Update [=> 1]@16 -> [=> field]@16");

edits.VerifySemantics(
[SemanticEdit(SemanticEditKind.Update, c => c.GetMember<IPropertySymbol>("C.P").GetMethod)],
Copy link
Member

Choose a reason for hiding this comment

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

I can't remember, should this also have a field add in the list of edits? Or is that bit automatic for properties?

Perhaps a test in https://github.com/dotnet/roslyn/blob/main/src/Compilers/CSharp/Test/Emit2/Emit/EditAndContinue/EditAndContinueTests.cs would be a good idea, to make sure the right metadata is emitted.

Copy link
Member Author

@DustinCampbell DustinCampbell Apr 24, 2025

Choose a reason for hiding this comment

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

Should this also have a field add in the list of edits?

I don't believe so. At least, I don't see an insert for the backing field in other auto-property tests. The insert of the field is implicitly tested by verifying the diagnostics below when the AddInstanceFieldToExistingType capability isn't specified. I'll take a look at adding a test or two on the compiler side as well.

Copy link
Member

Choose a reason for hiding this comment

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

The insert of the field is implicitly tested by verifying the diagnostics below when the AddInstanceFieldToExistingType capability isn't specified.

I missed this, that's a very good point.

Copy link
Member Author

Choose a reason for hiding this comment

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

Added compiler layer tests

Copy link
Member

Choose a reason for hiding this comment

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

We don't need the field insert. We just need to tell the compiler to emit the property and it will emit all symbols it needs to do so.

@DustinCampbell DustinCampbell requested a review from a team as a code owner April 24, 2025 17:29
validator: g =>
{
g.VerifyTypeDefNames("HotReloadException");
g.VerifyFieldDefNames("Code");
Copy link
Member

Choose a reason for hiding this comment

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

Hmm, where is "Code" coming from?

Copy link
Member Author

Choose a reason for hiding this comment

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

It's from HotReloadException.Code.

@DustinCampbell
Copy link
Member Author

@tmat: Is there anything you need before giving sign off?

@DustinCampbell DustinCampbell merged commit f3ecd54 into dotnet:main Apr 30, 2025
28 checks passed
@DustinCampbell DustinCampbell deleted the enc-field-access-in-auto-props branch April 30, 2025 18:34
@dotnet-policy-service dotnet-policy-service bot added this to the Next milestone Apr 30, 2025
@RikkiGibson RikkiGibson modified the milestones: Next, 18.0 P1 Aug 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Area-Interactive untriaged Issues and PRs which have not yet been triaged by a lead VSCode

Projects

None yet

Development

Successfully merging this pull request may close these issues.

EnC: implement support for field keyword in property accessors

4 participants