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

don't include implicit/explicit keywords when completing explicit interface operator #53938

Merged

Conversation

Youssef1313
Copy link
Member

@Youssef1313 Youssef1313 commented Jun 8, 2021

Fixes #53924

This adds a public API :(
Another solution would be to handle this case entirely in the completion provider, i.e, do displayText.Replace("implicit operator", "").Replace("explicit operator", "");, but it looks a bit ugly. I'm certainly open to any other ideas.

Test plan: #52221

/// ]]></code>
/// instead of:
/// <code><![CDATA[
/// static implicit I2<Test2>.implicit operator int(Test2 x)
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 see why we would ever format this text. That just feels like a bug.

Copy link
Member

Choose a reason for hiding this comment

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

i am a little confused how symboldisplay plays into this scenario. i would not expect completion to be using symboldisplay here. that feels like a core bug on its own to me.

Copy link
Member

Choose a reason for hiding this comment

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

That too.

Copy link
Member Author

Choose a reason for hiding this comment

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

var memberString = member.ToMinimalDisplayString(semanticModel, namePosition, s_signatureDisplayFormat);

:(

@CyrusNajmabadi @333fred Any suggestion on how to best approach this?

Copy link
Member

Choose a reason for hiding this comment

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

  1. kill me
  2. replace that code with code that just builds the right syntax for what we're generating. it seems not that hard right? it's just member name, type parameters, parameters, constraints.

Copy link
Member Author

Choose a reason for hiding this comment

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

@CyrusNajmabadi

replace that code with code that just builds the right syntax for what we're generating

I did that. The code isn't large as I was initially expecting. The only risk I see with this approach is regressing some edge cases, but I'll add more tests.

@Youssef1313 Youssef1313 marked this pull request as draft June 9, 2021 07:15
@Youssef1313 Youssef1313 force-pushed the explicit-interface-impl-completion branch from 55dfaf7 to cd11a40 Compare June 9, 2021 07:42
@Youssef1313 Youssef1313 force-pushed the explicit-interface-impl-completion branch from cd11a40 to 0b92d20 Compare June 9, 2021 07:53
@Youssef1313 Youssef1313 requested review from CyrusNajmabadi and 333fred and removed request for a team June 9, 2021 08:40
@Youssef1313 Youssef1313 marked this pull request as ready for review June 9, 2021 09:09
}

first = false;
AddType(parameter.Type, builder);
Copy link
Member

Choose a reason for hiding this comment

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

any concern about ref-kind?

Copy link
Member Author

Choose a reason for hiding this comment

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

@CyrusNajmabadi Yes. This was a bug. Fixed and added a test.

Copy link
Member

Choose a reason for hiding this comment

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

any need to add params?

Copy link
Member

Choose a reason for hiding this comment

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

any need to add constraints? i know it's an explicit interface, so normally no. but is there that funky case where we need to know if T? is unconstrained or not?

Copy link
Member Author

Choose a reason for hiding this comment

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

any need to add params?

Yes it definitely should be added. It was a working scenario. Fixed in latest commit.


any need to add constraints? i know it's an explicit interface, so normally no. but is there that funky case where we need to know if T? is unconstrained or not?

This is a scenario that doesn't work well on latest preview already.

image

The existing behavior is: no ? is added, and no "default" constraint is added.

I'll probably just add the ? for this PR and leave any potential improvements to address separately.

@Youssef1313 Youssef1313 changed the base branch from features/StaticAbstractMembersInInterfaces to main June 21, 2021 19:25
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.

Request changes
Submit feedback that must be addressed before merging.

Youssef1313 and others added 2 commits July 19, 2021 20:22
Co-authored-by: CyrusNajmabadi <cyrus.najmabadi@gmail.com>
@Youssef1313
Copy link
Member Author

@CyrusNajmabadi Can you review please? Thanks!

@Youssef1313
Copy link
Member Author

Ping @CyrusNajmabadi
Can you take a look please? Thanks!


first = false;
builder.Append(typeArgument.Name);
}
Copy link
Member

Choose a reason for hiding this comment

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

i would be 100% ok with a stringbuilder extension that takes a TEnumerable and a separator and does this logic :)

Copy link
Member Author

Choose a reason for hiding this comment

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

@CyrusNajmabadi A private extension just for this class, or somewhere else for wider usage?

Copy link
Member

Choose a reason for hiding this comment

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

somewhere else :)

@CyrusNajmabadi
Copy link
Member

I have a few suggestions. If you do not want to take them, just LMK.

@Youssef1313
Copy link
Member Author

@CyrusNajmabadi Thanks. I fixed those you pointed to in addition to other few bugs.

@Youssef1313
Copy link
Member Author

@CyrusNajmabadi This is ready for another look

@CyrusNajmabadi
Copy link
Member

Thanks!

auto-merge was automatically disabled January 20, 2022 22:20

Head branch was pushed to by a user without write access

Youssef1313 and others added 2 commits January 21, 2022 00:20
…plicitInterfaceMemberCompletionProvider.CompletionSymbolDisplay.cs

Co-authored-by: CyrusNajmabadi <cyrus.najmabadi@gmail.com>
@Youssef1313
Copy link
Member Author

@CyrusNajmabadi Auto-merge was disabled as I pushed commits. Can you re-enable? Thanks!

@CyrusNajmabadi CyrusNajmabadi merged commit ae23cba into dotnet:main Jan 21, 2022
@ghost ghost added this to the Next milestone Jan 21, 2022
@CyrusNajmabadi
Copy link
Member

Thanks!

@Youssef1313 Youssef1313 deleted the explicit-interface-impl-completion branch January 21, 2022 18:48
@RikkiGibson RikkiGibson modified the milestones: Next, 17.2.P1 Feb 4, 2022
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.

Completion for an explicit implementation of a conversion operator produces invalid code
6 participants