Rewrite rules for `sequence_`, `traverse_` and their counterparts

[satorg]

Since Cats v2.13.0 the following rewrites can be recommended:

• sequence_ -> sequenceVoid
• traverse_ -> traverseVoid
• nonEmptySequence_ -> nonEmptySequenceVoid
• nonEmptyTraverse_ -> nonEmptyTraverseVoid
• parSequence_ -> parSequenceVoid
• parTraverse_ -> parTraverseVoid
• parNonEmptySequence_ -> parNonEmptySequenceVoid
• parNonEmptyTraverse_ -> parNonEmptyTraverseVoid

See typelevel/cats#4611 and typelevel/cats#4682 for more details.

[satorg]

A question... Should the rule only emit warnings and suggest users do the renames themselves or do the renames on behalf of the users? As I can see, the MapSequence rule does the warnings job only: https://github.com/typelevel/typelevel-scalafix/blob/1914947a04dd15601f79f913c2a3318b6a2b1da8/modules/cats/rules/src/main/scala/org/typelevel/fix/MapSequence.scala#L22

[armanbilge]

I think this one has good potential to be a rewrite, because it's fairly straightforward. The goal is that code that compiled before the rewrite will still compile/behave the same after the rewrite.

For some rules, that's a little more fuzzy. For example, rewriting map(_ => x) to as(x) behaves differently if x is lazy (theoretically not important for correctness, but possibly has performance implications).

If you account for people writing non-RT code, then it gets even murkier. For example, map+ sequence is a workaround for https://github.com/typelevel/cats/issues/4176, so auto-rewriting that to traverse may not be what they want.

Maybe rewrites are overall still most useful, and people can use inline-comments to suppress the scalafix as a form of documentation that they are in one of these special cases. 🤷