-
Notifications
You must be signed in to change notification settings - Fork 4.2k
Fix IDE behavior and tests for some Primary Constructors scenarios #66896
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
Fix IDE behavior and tests for some Primary Constructors scenarios #66896
Conversation
|
@akhera99, @CyrusNajmabadi, @dotnet/roslyn-ide Please review. |
| class Goo(int x, int {|Definition:$$y|}) | ||
| { | ||
| public int y { get; } = [|y|]; | ||
| public int z { get; } => [|y|]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
curious about the removals here? was that intentional/needed? #Resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
curious about the removals here? was that intentional/needed?
I added dedicated test for this scenario. The property y declared above shadows the parameter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, gotcha. IMO, it would be better to leave the line in, but take off the [| |] around it (to make it clear that that 'y' is not considered a ref. But up to you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Put the lines back as suggested
| { | ||
| var updatedParameters = UpdateDeclaration(@struct.ParameterList.Parameters, signaturePermutation, CreateNewParameterSyntax); | ||
| return @struct.WithParameterList(@struct.ParameterList.WithParameters(updatedParameters).WithAdditionalAnnotations(changeSignatureFormattingAnnotation)); | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could the above three 'if' statements be merged into one?
Syntax question. is 'ParameterList' added to TypeDeclSyntax, or only these three subclasses. If the latter, could we consider actually moving up to TypeDeclSyntax and having it always be null for interfaces. Or have interfaces allow parsing them out (for error recovery) and then report errors that it's not allowed there. feels like it would help prevent a bunch of duplication in consumption code. #Resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could the above three 'if' statements be merged into one?
At the moment we do not have WithParameterList API on a base class and I prefer to not add it because it wouldn't be appropriate for all types derived from that base.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At the moment we do not have WithParameterList API on a base class and I prefer to not add it because it wouldn't be appropriate for all types derived from that base.
I'm totally fine with that for the current state of affairs. Can this be noted though for when we bring this to API review? I'd like to make an alternative case. But that's def not blocking this work now. Thanks! :)
|
|
||
| primaryConstructor = typeSymbol.InstanceConstructors.FirstOrDefault( | ||
| c => c.DeclaringSyntaxReferences.FirstOrDefault()?.GetSyntax() is RecordDeclarationSyntax); | ||
| c => c.DeclaringSyntaxReferences.FirstOrDefault()?.GetSyntax() is RecordDeclarationSyntax or ClassDeclarationSyntax or StructDeclarationSyntax); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| c => c.DeclaringSyntaxReferences.FirstOrDefault()?.GetSyntax() is RecordDeclarationSyntax or ClassDeclarationSyntax or StructDeclarationSyntax); | |
| c => c.DeclaringSyntaxReferences.FirstOrDefault()?.GetSyntax() is TypeDeclarationSyntax); |
| c => c.DeclaringSyntaxReferences.FirstOrDefault()?.GetSyntax() is RecordDeclarationSyntax or ClassDeclarationSyntax or StructDeclarationSyntax); | |
| c => c.DeclaringSyntaxReferences.FirstOrDefault()?.GetSyntax() is not ConstructorDeclarationSyntax); |
Though, actually, this logic slightly worries me. Won't this return 'true' for the implicitly created constructor for a struct that does not have an actual primary constructor? Maybe we should say that the syntax has to both be the DeclSyntax And the decl syntax has a primary constructor? #Resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer to follow the pattern established for records. TypeDeclarationSyntax would include interfaces and this is not my intention.
CyrusNajmabadi
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Some questions/suggestions, and a slight concern. But nothing blocking at all.
No description provided.