This feels a little like redoing some of the logic the parser is doing for us already, and will fall down if exclamation points are used for something else in future. For example there is a proposal for argument validation that would use it.

To me it makes more sense to simply check if the parent is SuppressNullableWarningExpression and return Keyword("nullForgiving") for that, and let the rest of the code flow as it did before.

@davidwengier I did that in the latest commit but just realized a problem with that approach.
For null forgiving operator, SuppressNullableWarningExpression won't always be the parent.
The parent could be MemberAccessExpression whose parent is SuppressNullableWarningExpression.
So, that will need traversing the tree up to make sure it'll work correctly.

Does it worth doing so?

By the way, I believe there are many other cases that aren't handled correctly. For example, the colon in inheritance vs ternary operator.

Do you see a way to refactor the whole thing instead of keeping special-casing more things? probably make it based on semantics instead of syntax?

The parent could be MemberAccessExpression whose parent is SuppressNullableWarningExpression.

What scenario would have this?

I looked again in SharpLab and it was just my eyes incorrectly seeing sibling nodes as parent/children 😄 . So this approach should just work.