False positive for the collection_alignment rule when "…" is used

[BobbyRohweder]

New Issue Checklist

• Updated SwiftLint to the latest version
• I searched for existing GitHub issues

Describe the bug

A false positive warning occurs for the collection_alignment Rule when using "…" in the first line.
Adding 2 more spaces to the second line will resolve the issue, and seems as if "…" is considered 3 characters.

Example:

NSAttributedString(string: "…", attributes: [.font: UIFont.systemFont(ofSize: 12, weight: .regular),
                                             .foregroundColor: UIColor(white: 0, alpha: 0.2)])

A clear and concise description of what the bug is.

Complete output when running SwiftLint, including the stack trace and command used

$ swiftlint lint

Error:

<failure message='All elements in a collection literal should be vertically aligned'>error:
Line:78 </failure>

Rules:

opt_in_rules:
    - collection_alignment

Environment

Swiftlint version: 0.50.3

[mildm8nnered]

The system does a lot of mapping between ellipsis and three dots. For example, on MacOS menu items defined with three dots, and those defined with the ellipsis will appear identical. This treatment can vary subtly between OS's - we had to update a unit test for Ventura on my product for a case where we were expecting to see three dots, but instead now got ellipsis, or possibly vice versa.

"Unicode recognizes a series of three period characters (U+002E) as compatibility equivalent (though not canonical) to the horizontal ellipsis character".

[mildm8nnered]

I think this could be tricky to fix in SwiftLint itself, because we're getting the locations via element.positionAfterSkippingLeadingTrivia, which is defined in SwiftSyntax, so that's where we're getting the wrong positions from.

In fact, print("length = \("…".utf8.count)") will produce 3, so the problem is even deeper than that.

The best workaround for you is probably just to use three dots instead - in almost all contexts, where these should be ellipsis, the OS will automatically render them correctly for you.

[SimplyDanny]

Thank you for the insights, @mildm8nnered! However, this issue is not specific to the ellipsis. We can observe the same for emoji. So I think this is a general issue with how SwiftLint interprets text.

It's not always right to go down to the encoding level. Here, it's about what's visible to the user. In the case of the ellipsis, it's 1 character ("…".count). In case of 🤷‍♂️, it's also 1 character but "🤷‍♂️".utf8.count == 13.