WIP: Possible alternate implementation of UseConsistentWhitespace CheckOperator feature

[Joel Davies (daviesj)]

PR Summary

OK, so this far from ready, but I wanted to get it out there as a suggestion. It all started with trying to work on unary operator issues describe in #1239. But after discovering the problem in #1606, I was thinking maybe the best thing would be to re-implement the feature and an idea of how to do it came to me.

I started by writing a bunch more tests (3a47f4a) both as a way to establish a baseline for how the feature behaves now, and to hopefully be a tool to help with any fixes for the linked issues. In order to come up with this list of tests, I looked through about_Operators and related topics. I added a test for any type of operator that I felt was somehow different, but didn't already have a test and could possibly fall into the category of operators that one might possibly want CheckOperator to enforce whitespace around (or to ignore).

Then, I wrote a new implementation (d3da1e4) which more-or-less corresponds with the current behavior, except (at least in my opinion) handles unary operators better and fixes the inconsistencies with bitwise operators between PS 5.1 and 7. Since it already passed the tests for most types of operators I decided to go ahead and write code that might handle the other types (3943377). I realize that that code may not be complete enough and maybe not all of those operators should be implemented.

Hopefully the code comments explain the strategy pretty well but I will add a couple things. The code for the visitor is the same as I used in PR #1566. Also, I chose to remove the IsOperator function because it wasn't used anywhere else, and the tests that would be used just to determine whether the token is an operator are so similar to the ones used to determine what sort of operator, I figured it would be simpler not to run through them twice.

With this implementation, it would also be reasonably easy to enforce no whitespace around operators like ++,--,-,! as described in #1239 (which could also easily be made optional). See possible implementation.

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Change is not breaking
• Make sure all .cs, .ps1 and .psm1 files have the correct copyright header
• Make sure you've added a new test if existing tests do not effectively test the code changed and/or updated documentation
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: to the beginning of the title and remove the prefix when the PR is ready.

[Christoph Bergmeister (bergmeister)]

Thanks for the detailed explanation. Happy to take that and looks ok to me. I see it's largely based on #1566, therefore we should aim to get that PR merged soon. Rob Holt (@rjmholt) Can you please give your final yes/no on that other PR as you've already reviewed it before? I myself am happy with the other PR already.
After that the diff in this PR will be much smaller but as you said I can already see that the main diff will be just the change of using your Ast visitor instead of TokenTraits.HasTrait.
This PR will likely cause a merge conflict for my PR #1602 but I am happy to accept that.

[Christoph Bergmeister (bergmeister)]

Suggested change

	foreach(LinkedListNode<Token>tokenNodeintokenOperations.GetTokenNodes((t)=>true))
	foreach(LinkedListNode<Token>tokenNodeintokenOperations.GetTokenNodes(()=>true))

[Rob Holt (rjmholt)]

Converting this to a draft while it remains a WIP