Would this be better aschar.IsWhiteSpace(line[line.Length - 1])?

@rjmholt because of

• readablity
• perfomance
• covering the variety of unicode chars? from the docshere, it would probably be good but what about theUnicodeCategory.LineSeparator char? I don't have much Unicode experience to make a judgement call here tbh if this list includes too much or not
  

My thinking here is actually just thatPowerShell uses that API to see whitespace.

Given how we split the string already, it's possibly dangerous to go by unicode whitespace, but possibly not...

I suspect that really this won't make much difference; leaving non-ASCII whitespace at the ends of lines isn't something I can imagine being an issue for anyone really.

Ok, so that sounds more like a tendency to useIsWhiteSpace? I'd be OK with that, you are right that the impact is probably quite low, especially since this rules is not enabled by default for vs-code users.

This makes me wonder: if we're just trying to find the extents of trailing whitespace, there's no need to split the string at all; we should just read through ourselves without allocating all these strings... But too much burden for this PR!

Hmm, yh, I hear what you say, I guess for perf what counts is the 80-20 rule :-) Technically speakingstring.IndexOf would probably the fastest way of finding the indices where\s\r or \s\n occurs....
I'm aware of lot's of other small micro optimisations that one can make and even tried some but they didn't have a measurable outcome. Therefore I am focussed on just fixing what gives at least a measurable return.