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

Report info diagnostic for field and value in property accessors regardless of language version #73952

Merged
merged 5 commits into from
Jun 13, 2024

Conversation

cston
Copy link
Member

@cston cston commented Jun 12, 2024

No description provided.

@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Compilers untriaged Issues and PRs which have not yet been triaged by a lead labels Jun 12, 2024
@cston cston force-pushed the keyword-diagnostic-more branch from 9f69b45 to d3615b6 Compare June 13, 2024 03:03
@cston cston changed the title Report diagnostic for field in property accessors regardless of language version Report info diagnostic for field and value in property accessors regardless of language version Jun 13, 2024
@cston cston marked this pull request as ready for review June 13, 2024 05:04
@cston cston requested a review from a team as a code owner June 13, 2024 05:04
@cston cston requested a review from jaredpar June 13, 2024 05:04
@@ -6866,7 +6866,7 @@ To remove the warning, you can use /reference instead (set the Embed Interop Typ
<value>Compiling requires binding the lambda expression many times. Consider declaring the lambda expression with explicit parameter types, or if the containing method call is generic, consider using explicit type arguments.</value>
</data>
<data name="INF_IdentifierConflictWithContextualKeyword" xml:space="preserve">
<value>'{0}' is a contextual keyword, with a specific meaning, starting in language version {1}. Use '@{0}' to avoid a breaking change when compiling with language version {1} or later.</value>
<value>'{0}' is a contextual keyword, with a specific meaning, in language version {1} or later. Use '@{0}' to avoid a breaking change when compiling with different language versions.</value>
Copy link
Member

Choose a reason for hiding this comment

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

Not sure I understand the second half of this message changing; I actually find it clearer than the new wording.

Copy link
Member Author

Choose a reason for hiding this comment

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

I wanted wording that made sense regardless of whether the code was compiled with -langversion:12 (or earlier) or -langversion:13 (or later). The previous message said "to avoid a breaking change when compiling with version 13 or later" but that seemed confusing when compiling with 13.

I'm open to suggestions on wording.

Copy link
Member

Choose a reason for hiding this comment

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

I don't think the current message adequately describes the issue at all. Here's my workshop:

Suggested change
<value>'{0}' is a contextual keyword, with a specific meaning, in language version {1} or later. Use '@{0}' to avoid a breaking change when compiling with different language versions.</value>
<value>'{0}' is a contextual keyword, with a specific meaning in property accessors, in language version {1} or later. Use '@{0}' to avoid potential breaking changes in property accessors when compiling with different language versions.</value>

Copy link
Contributor

@RikkiGibson RikkiGibson Jun 13, 2024

Choose a reason for hiding this comment

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

'field' is a contextual keyword in property accessors starting in C# 13. Use '@field' instead.

IMO this message gives all the key information and then stops, which is good for user comprehension. People who want more details on why exactly they're being asked to do this and what field and @field will mean in the future can hit F1.

Copy link
Member Author

Choose a reason for hiding this comment

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

How about "to avoid breaking changes ..." rather than "to avoid potential breaking changes ..."? (We're only reporting the diagnostic when binding to a different symbol, so the diagnostic is quite likely identifying a breaking change.)

Copy link
Member

Choose a reason for hiding this comment

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

I think I like Rikki's suggestion best.

@@ -1906,7 +1906,7 @@ class C
static int field;
static long x { set { System.Console.WriteLine($""setX {value}""); } }
static string y { get; set; }
static ref int z { get { return ref field; } }
static ref int z { get { return ref @field; } }
Copy link
Contributor

Choose a reason for hiding this comment

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

No need to address in this PR. But, are we considering reporting anything in the following scenario, after field feature ships?

class C
{
    int field;
    public int Prop => field; // doesn't read 'C.field'.
}

Essentially some kind of guardrail to try and avoid surprise here when field doesn't mean what the user thinks it means in the property accessor. For example, a nudge to declare int field as int @field, to signal they understand the new behavior in property accessors. (It feels like a warning on the usage of field when a symbol with that name is in scope is too cumbersome/hard to suppress.)

@cston cston merged commit c42c063 into dotnet:main Jun 13, 2024
24 checks passed
@cston cston deleted the keyword-diagnostic-more branch June 13, 2024 22:11
@dotnet-policy-service dotnet-policy-service bot added this to the Next milestone Jun 13, 2024
@jjonescz jjonescz modified the milestones: Next, 17.11 P3 Jun 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Compilers Feature - Field Keyword untriaged Issues and PRs which have not yet been triaged by a lead
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants