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

Partial properties: public API and IDE features #73603

Merged

Conversation

RikkiGibson
Copy link
Contributor

Test plan: #73090
Public API design: #73411

@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Compilers untriaged Issues and PRs which have not yet been triaged by a lead labels May 20, 2024
Copy link
Member

@CyrusNajmabadi CyrusNajmabadi left a comment

Choose a reason for hiding this comment

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

ide side lgtm.

@CyrusNajmabadi
Copy link
Member

@RikkiGibson fixed. Thanks.

The issue here was that we were losing which part this was (the def or impl). So when sending from OOP to local host we picked up the wrong symbol.

@RikkiGibson
Copy link
Contributor Author

Thank you Cyrus!

@CyrusNajmabadi
Copy link
Member

Done with pass. IDE still lgtm.

@RikkiGibson
Copy link
Contributor Author

My plan is to -launch this PR branch locally, continue to play around with IDE features/behaviors, and determine if it meets the min-bar.

There are many places where the Partial*Part APIs on methods are being used in the features and workspaces layers already. I will identify where it's possible that use of the partial property APIs are desired as well, and add issue links to those locations.

@RikkiGibson RikkiGibson marked this pull request as ready for review May 23, 2024 21:04
@RikkiGibson RikkiGibson requested review from a team as code owners May 23, 2024 21:04
@RikkiGibson RikkiGibson removed the request for review from a team May 23, 2024 21:08
@RikkiGibson RikkiGibson requested review from jcouv and removed request for a team May 23, 2024 21:08
@RikkiGibson
Copy link
Contributor Author

@jcouv for review of the compiler side changes

/// If this is a partial property implementation part, returns the corresponding
/// definition part. Otherwise null.
/// </summary>
IPropertySymbol? PartialDefinitionPart { get; }
Copy link
Member

Choose a reason for hiding this comment

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

Looking at the usages of the existing public APIs for partial methods, I feel there are more IDE scenario and potentially EnC scenarios that will need to be adjusted for partial properties/indexers. Are those known/understood?

Copy link
Member

Choose a reason for hiding this comment

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

IDE scenarios outside of hte min-bar are entirely optional to change.

MethodSymbol method => method.PartialImplementationPart,
SourcePropertySymbol property => property.PartialImplementationPart,
_ => null
};
Copy link
Member

@jcouv jcouv May 24, 2024

Choose a reason for hiding this comment

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

This PR includes some tests for GetDeclaredSymbol public API. Do we have tests for GetDeclaredSymbol on the parameters of a partial indexer?
It looks like there is additional logic in this file that looks at PartialDefinitionPart for partial methods for that scenario, which might need to be updated to account for partial properties. #Resolved

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have addressed the remaining usages of PartialDefinition/ImplementationPart in this file.

There is one other usage of PartialDefinitionPart which doesn't need to account for properties, because it is for a method type parameter scenario, and properties don't have type parameters.

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.

Done with review pass of compiler changes (iteration 14)

@@ -2033,9 +2037,7 @@ internal override ImmutableArray<ISymbol> GetDeclaredSymbols(BaseFieldDeclaratio
return null;
}

return
GetParameterSymbol(method.Parameters, parameter, cancellationToken) ??
((object)method.PartialDefinitionPart == null ? null : GetParameterSymbol(method.PartialDefinitionPart.Parameters, parameter, cancellationToken));
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I believe this check of 'PartialDefinitionPart' did not make sense. The containing method GetMethodParameterSymbol(ParameterSyntax, CancellationToken) works by grabbing the parent MemberDeclarationSyntax of the given ParameterSyntax. It then gets the symbol for the MemberDeclarationSyntax, and searches the symbol's parameters for one which matches the original input ParameterSyntax.

We should expect that GetDeclaredSymbol returns the correct partial symbol corresponding to the declaration syntax which was passed in. So there is no benefit, in the case where searching the parameters of the symbol we got resulted in no match, to also searching the parameters of the definition part which was related to the symbol we got.

@@ -2165,10 +2164,7 @@ public override ITypeParameterSymbol GetDeclaredSymbol(TypeParameterSyntax typeP
return this.GetTypeParameterSymbol(typeSymbol.TypeParameters, typeParameter).GetPublicSymbol();

case MethodSymbol methodSymbol:
return (this.GetTypeParameterSymbol(methodSymbol.TypeParameters, typeParameter) ??
((object)methodSymbol.PartialDefinitionPart == null
Copy link
Contributor Author

@RikkiGibson RikkiGibson May 28, 2024

Choose a reason for hiding this comment

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

I think this check didn't make sense for the same reason as #73603 (comment).

@jcouv jcouv self-assigned this May 28, 2024
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 19)

@RikkiGibson RikkiGibson requested a review from a team May 28, 2024 22:47
@RikkiGibson RikkiGibson requested a review from a team May 28, 2024 22:53
@RikkiGibson
Copy link
Contributor Author

@dotnet/roslyn-compiler for second review

@RikkiGibson
Copy link
Contributor Author

@dotnet/roslyn-compiler for review

Copy link
Member

@cston cston left a comment

Choose a reason for hiding this comment

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

Compiler changes LGTM.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Compilers 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.

4 participants