Skip to content

Conversation

@sharwell
Copy link
Contributor

@sharwell sharwell commented Jun 1, 2017

Currently SeparatedSyntaxList<SyntaxNode> can be implicitly cast to SeparatedSyntaxList<T> for any syntax type T. This is not a safe or meaningful conversion, so this change seeks to remove it.

  • The implicit operator is left in place using its underlying metadata signature to preserve binary compatibility with previous builds
  • The implicit operator is marked obsolete to prevent future use of this unsafe method
  • No explicit operator could be added because the implicit operator was not removed, so a CastDown method is added to provide the functionality via an explicit method An explicit operator alongside the op_Implicit method using the operator syntax.

@jcouv
Copy link
Member

jcouv commented Apr 18, 2018

Given that there was no activity on this PR in a while, I'm marking it as "for personal review" for now (so it doesn't show up in our daily list of PRs to review). Thanks

@jcouv jcouv added the PR For Personal Review Only The PR doesn’t require anyone other than the developer to review it. label Apr 18, 2018
@sharwell sharwell marked this pull request as draft April 8, 2020 22:30
Base automatically changed from master to main March 3, 2021 23:51
@sharwell sharwell marked this pull request as ready for review May 26, 2022 00:19
@sharwell sharwell requested review from a team as code owners May 26, 2022 00:19
@sharwell sharwell removed PR For Personal Review Only The PR doesn’t require anyone other than the developer to review it. cla-already-signed labels May 26, 2022
@sharwell
Copy link
Contributor Author

@jcouv this has been updated again

@AlekseyTs
Copy link
Contributor

  • The implicit operator is left in place to preserve binary compatibility with previous builds
  • The implicit operator is marked obsolete to prevent future use of this unsafe method
  • No explicit operator could be added because the implicit operator was not removed, so a CastDown method is added to provide the functionality via an explicit method

Have you considered replacing the implicit operator with a regular method with the same name an signature instead? That should take care of binary compatibility. Then we can add an explicit operator.

@sharwell
Copy link
Contributor Author

Have you considered replacing the implicit operator with a regular method with the same name an signature instead? That should take care of binary compatibility. Then we can add an explicit operator.

💭 No, but I'll try now

@CyrusNajmabadi
Copy link
Member

Have you considered replacing the implicit operator with a regular method with the same name an signature instead? That should take care of binary compatibility. Then we can add an explicit operator.

TIL! :-)

@sharwell
Copy link
Contributor Author

@AlekseyTs Now updated to preserve the implicit operator using its metadata name instead of implicit operator.

public virtual SyntaxList<TNode> VisitList<TNode>(SyntaxList<TNode> list) where TNode : SyntaxNode
{
SyntaxListBuilder? alternate = null;
SyntaxListBuilder<TNode> alternate = default;
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this change primarily related to the stated goal of the PR? If not, please consider separating it into its own PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It is related. SyntaxListBuilder produced a SyntaxList<SyntaxNode> which needs an explicit downcast. SyntaxListBuilder<TNode> produces SyntaxList<TNode> and removes the need for a downcast.

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.

Changes under Compilers LGTM, modulo possibly unrelated change in CSharpSyntaxRewriter.cs

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.

Changes under Compilers LGTM (commit 9)

@AlekseyTs
Copy link
Contributor

@dotnet/roslyn-compiler For the second review.

Copy link
Member

@333fred 333fred left a comment

Choose a reason for hiding this comment

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

Changes under compilers look fine, but not signing off until build and test issues are corrected.

Copy link
Member

@333fred 333fred 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 (commit 11)

@jaredpar
Copy link
Member

@sharwell this PR has appropriate sign offs. It's a bit stale so we probably want to re-run CI here. But are you intending to move forward with this? If not I would like to close to get it off our review queue.

@jaredpar jaredpar marked this pull request as draft March 30, 2023 14:25
@jaredpar
Copy link
Member

Have not heard back so moving to draft.

@sharwell
Copy link
Contributor Author

@jaredpar Sorry got hit by the command line build failures when I tried to update. Trying again locally and hopefully should work out.

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.

9 participants