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

New Function Pointer Syntax #45684

Merged
13 commits merged into from
Jul 10, 2020
Merged

Conversation

333fred
Copy link
Member

@333fred 333fred commented Jul 6, 2020

This updates function pointers to use the new syntax decided on in LDM. This is syntax-level changes only: the updated calling convention binding will come in the next PR.

Fixes #44312.

@333fred 333fred requested review from AlekseyTs and a team July 7, 2020 17:00
@333fred 333fred marked this pull request as ready for review July 7, 2020 17:00
@333fred
Copy link
Member Author

333fred commented Jul 7, 2020

@dotnet/roslyn-compiler @AlekseyTs, this is now ready for review.

@dotnet/roslyn-ide, this includes syntax changes to function pointer types, and formatter/intellisense context fixes to ensure the existing tests still pass. We'll still need to make intellisense changes for the calling convention location at a later point.

await AssertFormatAsync(expected, content);
}

[Fact(Skip = "PROTOTYPE(func-ptr): Even though the rule is returning put a space, it's getting ignored, resulting in delegate*invalid <")]
Copy link
Member Author

Choose a reason for hiding this comment

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

I'm assuming that this is because invalid is parsed as trivia on a missing managed or unmanaged token? Those two are the only valid token types for the spot.

Copy link
Member

Choose a reason for hiding this comment

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

The "invalid" token isn't being parsed into the calling convention position? It looks based on the formatting change that's what you intended, right?

Copy link
Member Author

Choose a reason for hiding this comment

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

It is parsed into the calling convention position, it's parsed as trivia on a missing managed token.


In reply to: 451061448 [](ancestors = 451061448)

Copy link
Member

Choose a reason for hiding this comment

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

So I guess if the formatter's rule is we don't touch things around missing stuff, then maybe the behavior you're seeing is correct. Once the user has typed correct code, it'll format correctly; if the user put their code into a broken state while they're doing other editing, not touching is fine for that small window.

@@ -961,15 +961,27 @@ public static bool IsDefaultExpressionContext(this SyntaxTree syntaxTree, int po
{
case SyntaxKind.LessThanToken:
case SyntaxKind.CommaToken:
return token.Parent is FunctionPointerTypeSyntax;
return token.Parent is FunctionPointerParameterList;
Copy link
Member

@jasonmalinowski jasonmalinowski Jul 7, 2020

Choose a reason for hiding this comment

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

Looks like you can delete the reference to #39865 now on line 959. #Resolved

await AssertFormatAsync(expected, content);
}

[Fact(Skip = "PROTOTYPE(func-ptr): Even though the rule is returning put a space, it's getting ignored, resulting in delegate*invalid <")]
Copy link
Member

Choose a reason for hiding this comment

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

The "invalid" token isn't being parsed into the calling convention position? It looks based on the formatting change that's what you intended, right?

Comment on lines +335 to +342
switch (currentKind)
{
case SyntaxKind.IdentifierToken:
case SyntaxKindEx.ManagedKeyword:
case SyntaxKindEx.UnmanagedKeyword:
return CreateAdjustSpacesOperation(1, AdjustSpacesOption.ForceSpacesIfOnSingleLine);
}
}
Copy link
Member

Choose a reason for hiding this comment

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

If we just checked that the currentToken is the FunctionPointerCallingConvention's ManagedSpecifier then we can remove this block, right? And we're having to do this because of the funkiness around not being able to reference new syntax node types in our code?

Copy link
Member Author

@333fred 333fred Jul 7, 2020

Choose a reason for hiding this comment

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

Yeah, we could accomplish it that way. And yes, it would rely on new syntax node types.


In reply to: 451066787 [](ancestors = 451066787)

Copy link
Member

Choose a reason for hiding this comment

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

@333fred If you could either do that work or just file a bug to do it, I think I'd feel better since this then is a bit more flexible around precisely what we might get out of the parser.

Copy link
Member Author

Choose a reason for hiding this comment

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

Filed #45897.

* Revert unneeded publicapi file changes.
* Simplify handling in some IDE code.
@AlekseyTs
Copy link
Contributor

AlekseyTs commented Jul 8, 2020

Done with review pass (iteration 8) #Closed

@333fred
Copy link
Member Author

333fred commented Jul 8, 2020

Because the API no longer exists.


In reply to: 655220662 [](ancestors = 655220662)


Refers to: src/Compilers/CSharp/Portable/GlobalSuppressions.cs:41 in c4be137. [](commit_id = c4be137, deletion_comment = True)

* Rename ManagedSpecifier for clarity.
* Handle more cases in symbol binding and increase code clarity.
* Deduplicate type checks when binding parameters.
@333fred
Copy link
Member Author

333fred commented Jul 8, 2020

@AlekseyTs addressed feedback.


In reply to: 655231532 [](ancestors = 655231532)

@AlekseyTs
Copy link
Contributor

AlekseyTs commented Jul 9, 2020

Done with review pass (iteration 10) #Closed

@333fred
Copy link
Member Author

333fred commented Jul 9, 2020

@AlekseyTs addressed feedback.


In reply to: 656247690 [](ancestors = 656247690)

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.

LGTM (iteration 11), modulo the remaining use of Text property #45684 (review)

@333fred
Copy link
Member Author

333fred commented Jul 9, 2020

@dotnet/roslyn-compiler for a second review.

@333fred
Copy link
Member Author

333fred commented Jul 9, 2020

@jasonmalinowski did you have any more comments?

}

return token.Parent is ParameterSyntax { Parent: FunctionPointerTypeSyntax _ };
return token switch
Copy link
Member

Choose a reason for hiding this comment

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

You might be able to merge this and the previous switch into a single pattern patch...

Copy link
Member Author

Choose a reason for hiding this comment

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

I didn't want to duplicate the parent is check. When we can use C# 9 or patterns this can be cleaned up :)

Comment on lines +335 to +342
switch (currentKind)
{
case SyntaxKind.IdentifierToken:
case SyntaxKindEx.ManagedKeyword:
case SyntaxKindEx.UnmanagedKeyword:
return CreateAdjustSpacesOperation(1, AdjustSpacesOption.ForceSpacesIfOnSingleLine);
}
}
Copy link
Member

Choose a reason for hiding this comment

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

@333fred If you could either do that work or just file a bug to do it, I think I'd feel better since this then is a bit more flexible around precisely what we might get out of the parser.

Copy link
Member

@jasonmalinowski jasonmalinowski left a comment

Choose a reason for hiding this comment

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

Looks good, regarding the two formatting tests I think you should update the baseline to lock the current behavior; if the rule is we don't touch spacing of tokens when something is missing, then the behavior is actually expected. It's just as likely somebody got themselves into that broken state and doesn't want to be fighting with the formatter while stuff is clearly broken.

Other request is to either move some code to use the types to simplify the formatter checks, or file a bug on the IDE for later cleanup. Your call.

await AssertFormatAsync(expected, content);
}

[Fact(Skip = "PROTOTYPE(func-ptr): Even though the rule is returning put a space, it's getting ignored, resulting in delegate*invalid <")]
Copy link
Member

Choose a reason for hiding this comment

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

So I guess if the formatter's rule is we don't touch things around missing stuff, then maybe the behavior you're seeing is correct. Once the user has typed correct code, it'll format correctly; if the user put their code into a broken state while they're doing other editing, not touching is fine for that small window.

await AssertFormatAsync(expected, content);
}

[Fact(Skip = "PROTOTYPE(func-ptr): Even though the rule is returning put a space, it's getting ignored, resulting in delegate*invalid [")]
Copy link
Member

Choose a reason for hiding this comment

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

Ditto: as long s it's formatting the stuff that it does understand, I guess that's good.

@333fred
Copy link
Member Author

333fred commented Jul 10, 2020

@dotnet/roslyn-compiler for a second review please

@RikkiGibson
Copy link
Contributor

Taking a look

* Enable tests as appropriate
* Fix doc comments
* Remove unnecessary generic parameters.
Copy link

@ghost ghost left a comment

Choose a reason for hiding this comment

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

Auto-approval

@ghost ghost merged commit ef8ca5a into dotnet:features/function-pointers Jul 10, 2020
@333fred 333fred deleted the new-syntax branch July 10, 2020 23:31
This pull request was closed.
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.

6 participants