Skip to content

Change "data" to "record"#44841

Merged
10 commits merged intodotnet:features/recordsfrom
agocke:record-keyword
Jun 4, 2020
Merged

Change "data" to "record"#44841
10 commits merged intodotnet:features/recordsfrom
agocke:record-keyword

Conversation

@agocke
Copy link
Member

@agocke agocke commented Jun 3, 2020

Resolves #44676

Adds a new "record" declaration kind and enables when parsing as C#
preview. If C# preview is not enabled, parsing is unchanged.

This PR builds on #44812. Only the last commit is relevant.

This PR takes out the parsing of primary constructors for classes and structs. In retrospect this may have been a mistake since it may have been more work dealing with the broken parsing than semantic errors and fix-ups, but there should be no bad effects aside from diagnostic quality.

@agocke agocke requested review from a team as code owners June 3, 2020 22:35
@agocke agocke requested a review from a team June 3, 2020 22:35
@gafter
Copy link
Member

gafter commented Jun 3, 2020

Is there a preferred order for reviewing these 544 commits?

@agocke
Copy link
Member Author

agocke commented Jun 3, 2020

@gafter

This PR builds on #44812. Only the last commit is relevant.

@agocke
Copy link
Member Author

agocke commented Jun 3, 2020

I'll reset this PR shortly, when the other one is merged.

Copy link
Member

Choose a reason for hiding this comment

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

Are there any tests that show the parsing "variants" inside namespaces and/or types? It would be nice if we also get a FeatureInPreview diagnostic there. I'm guessing parsing will just let it through and binding will fail to find a type named 'record'.

I feel like if it's not too difficult to achieve we should try to make sure the workflow of "install VS preview, pop open a C# file in my existing project, and just start using the preview feature" will work. Even something that just notices when a method that returns an ErrorType with the identifier 'record' and adds an additional FeatureInPreview diagnostic seems adequate.

Also, is there any chance that syntax nodes will be reused when changing the LangVersion in an open project? I'm guessing no because today you have to re-parse to get the right diagnostics, but figured it was worth checking.

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 would certainly be useful to get the "FeatureInPreview" diagnostic but I'm going to say that's out-of-scope for this PR.

Also, is there any chance that syntax nodes will be reused when changing the LangVersion in an open project?

Nope, changing the parse options always requires reparsing every syntax tree from scratch.

@AlekseyTs
Copy link
Contributor

@agocke Could you re-base this PR?

Adds a new "record" declaration kind and enables when parsing as C#
preview. If C# preview is not enabled, parsing is unchanged.
@agocke
Copy link
Member Author

agocke commented Jun 4, 2020

Done

@jcouv
Copy link
Member

jcouv commented Jun 4, 2020

I'll get started on IDE integration starting from this PR. Not sure all the impact yet, but I expect significant.

@AlekseyTs
Copy link
Contributor

AlekseyTs commented Jun 4, 2020

    public static SyntaxKind GetTypeDeclarationKind(SyntaxKind kind)

Should this method be adjusted? #Closed


Refers to: src/Compilers/CSharp/Portable/Syntax/SyntaxKindFacts.cs:788 in fdb60ac. [](commit_id = fdb60ac, deletion_comment = False)

@AlekseyTs
Copy link
Contributor

AlekseyTs commented Jun 4, 2020

            // contextual keywords

Should this section be adjusted? #Closed


Refers to: src/Compilers/CSharp/Portable/Syntax/SyntaxKindFacts.cs:1585 in fdb60ac. [](commit_id = fdb60ac, deletion_comment = False)

@AlekseyTs
Copy link
Contributor

        for (int i = (int)SyntaxKind.YieldKeyword; i <= (int)SyntaxKind.InitKeyword; i++)

Should this be adjusted?


Refers to: src/Compilers/CSharp/Portable/Syntax/SyntaxKindFacts.cs:1074 in fdb60ac. [](commit_id = fdb60ac, deletion_comment = False)

case SyntaxKind.InterfaceDeclaration:
case SyntaxKind.DelegateDeclaration:
case SyntaxKind.EnumDeclaration:
case SyntaxKind.RecordDeclaration:
Copy link
Contributor

Choose a reason for hiding this comment

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

case SyntaxKind.RecordDeclaration: [](start = 16, length = 34)

Please make sure we have targeted tests for all modified APIs in this file.

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 looked around and didn't find any tests for these APIs, it usually looks like we rely on the parsing tests to validate that contextual tokens are properly lexed. Do you want me to add new tests?

Copy link
Contributor

Choose a reason for hiding this comment

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

Do you want me to add new tests?

At least add tests for those that you missed and existing tests didn't catch the fact, or add a note to Test Plan to follow up


In reply to: 435439309 [](ancestors = 435439309)

DiagnosticBag diagnostics)
: base(containingType, syntax.GetReference(), ImmutableArray.Create(location), SyntaxFacts.HasYieldOperations(syntax))
{
Debug.Assert(syntax.IsKind(SyntaxKind.ConstructorDeclaration) || syntax.IsKind(SyntaxKind.ClassDeclaration) || syntax.IsKind(SyntaxKind.StructDeclaration));
Copy link
Contributor

@AlekseyTs AlekseyTs Jun 4, 2020

Choose a reason for hiding this comment

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

SyntaxKind.ClassDeclaration [](start = 91, length = 27)

Please make sure that all the places in the compiler that check for SyntaxKind.ClassDeclaration or ClassDeclarationSyntax are properly adjusted to handle records as well. #Closed

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 went through all of them and found a bunch more places. I don't want to delay this PR to add tests for all the places, so I added https://github.com/dotnet/roslyn/projects/57#card-39516963 to follow-up

@RikkiGibson
Copy link
Member

release_64 failure appears to be a stack size regression.

@AlekseyTs
Copy link
Contributor

AlekseyTs commented Jun 4, 2020

Done with review pass (iteration 2) #Closed

SyntaxKind kind,
CSharpSyntaxNode syntax)
{
Debug.Assert(
Copy link
Member

@jcouv jcouv Jun 4, 2020

Choose a reason for hiding this comment

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

Why remove the assertion? #Closed

Copy link
Member Author

@agocke agocke Jun 4, 2020

Choose a reason for hiding this comment

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

ToDeclarationKind one line below will fire an exception in all instances if the assert isn't followed, so this just feels like duplication #Closed

}

[Fact]
[Fact(Skip = "record struct")]
Copy link
Member

Choose a reason for hiding this comment

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

nit: link to issue would be better. Or add note to test plan to unskip all tests.

IL_0016: call ""object..ctor()""
IL_001b: ret
}");
}
Copy link
Member

Choose a reason for hiding this comment

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

Let's keep a test for data class and maybe even data record (both errors)

}

[Fact]
public void InvalidBase()
Copy link
Member

Choose a reason for hiding this comment

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

InvalidBase [](start = 20, length = 11)

nit: strange test name for this scenario

Copy link
Contributor

@AlekseyTs AlekseyTs left a comment

Choose a reason for hiding this comment

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

LGTM (iteration 7)

@jcouv jcouv self-assigned this Jun 4, 2020
Copy link
Member

@jcouv jcouv left a comment

Choose a reason for hiding this comment

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

LGTM Thanks (iteration 7)

Copy link
Member

@jasonmalinowski jasonmalinowski left a comment

Choose a reason for hiding this comment

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

Signing off on the (trivial) IDE portion. Compiler portion not reviewed.

@RikkiGibson
Copy link
Member

It appears that DeeplyNestedGeneric is still failing.

@agocke
Copy link
Member Author

agocke commented Jun 4, 2020

I'm gonna temporarily reduce the required depth here to get this in. We can fix it up as a bug.

Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

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

Auto-approval

@ghost ghost merged commit 5e8c7ad into dotnet:features/records Jun 4, 2020
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants