Conversation
|
Is there a preferred order for reviewing these 544 commits? |
|
I'll reset this PR shortly, when the other one is merged. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
|
@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.
|
Done |
src/Compilers/CSharp/Portable/Symbols/Source/SourceConstructorSymbolBase.cs
Outdated
Show resolved
Hide resolved
src/Compilers/CSharp/Portable/Symbols/Synthesized/Records/SynthesizedRecordConstructor.cs
Outdated
Show resolved
Hide resolved
src/Compilers/CSharp/Portable/Symbols/Source/SourceConstructorSymbolBase.cs
Outdated
Show resolved
Hide resolved
|
I'll get started on IDE integration starting from this PR. Not sure all the impact yet, but I expect significant. |
| case SyntaxKind.InterfaceDeclaration: | ||
| case SyntaxKind.DelegateDeclaration: | ||
| case SyntaxKind.EnumDeclaration: | ||
| case SyntaxKind.RecordDeclaration: |
There was a problem hiding this comment.
case SyntaxKind.RecordDeclaration: [](start = 16, length = 34)
Please make sure we have targeted tests for all modified APIs in this file.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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)); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
|
release_64 failure appears to be a stack size regression. |
|
Done with review pass (iteration 2) #Closed |
| SyntaxKind kind, | ||
| CSharpSyntaxNode syntax) | ||
| { | ||
| Debug.Assert( |
There was a problem hiding this comment.
Why remove the assertion? #Closed
There was a problem hiding this comment.
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")] |
There was a problem hiding this comment.
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 | ||
| }"); | ||
| } |
There was a problem hiding this comment.
Let's keep a test for data class and maybe even data record (both errors)
| } | ||
|
|
||
| [Fact] | ||
| public void InvalidBase() |
There was a problem hiding this comment.
InvalidBase [](start = 20, length = 11)
nit: strange test name for this scenario
docs/compilers/CSharp/Compiler Breaking Changes - post VS2019.md
Outdated
Show resolved
Hide resolved
jasonmalinowski
left a comment
There was a problem hiding this comment.
Signing off on the (trivial) IDE portion. Compiler portion not reviewed.
|
It appears that DeeplyNestedGeneric is still failing. |
|
I'm gonna temporarily reduce the required depth here to get this in. We can fix it up as a bug. |
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.