[SR-11798] Scrunching of Range Operators Breaks Code

[apple]

[SR-11798] Scrunching of Range Operators Breaks Code

[swift-ci]

Comment by Jeremy David Giesbrecht (JIRA)

I think pull request #91 aimed to solve this? Attn: @allevato

I just discovered it can also break if the upperBound starts with a dot, such as an enumeration case:

let range: ClosedRange<SomeEnumeration> = .caseFive ... .caseTen

Did your fix happen to handle that too or not?

[allevato]

The original PR didn't handle that case, because it only considered following tokens that were `prefixOperator`s, whereas the case above is `prefixPeriod` because it's not "technically" an operator in the case of implicit member references.

#98 addresses this case.

Arguably, a safer way to check this would be to simply check the previous and next characters to see if they're operator code points, but I don't really want to hardcode that list into the formatter—after all, the whole point of using the compiler's syntax parser is to have it do the work so we don't have to duplicate it.

@akyrtzi, maybe the syntax parser library could be extended to have generally useful utility functions, like "is this character an identifier character or operator character"?

[allevato]

#98 has been merged so this should be fixed now. (It, among other commits, still needs to be cherry-picked into the 5.1 branch.)