Refactor & Optimize EmptyLineAfterSig

[sambostock]

The previous implementation would traverse the tokens in the file each time it would analyze a sig until it found the corresponding method definition. This would take additional time the further we got into a file, as we would have to re-traverse all tokens so far.

This new implementation simply looks for the next node after the sig, confirms it is the method definition, and calculates offsets for the lines in between.

This also migrates from this class from the deprecated Cop parent class to Base.

---

When run across some of the largest files in the Shopify monolith, we see a > 2,000x improvement.¹

EmptyLineAfterSig#on_signature
Before		After		Change
Time Spent	Percentage of Total Samples	Time Spent	Percentage of Total Samples	Speedup Factor	Percentage Improvement
7.10s	13%	1.97ms	<0.01%	3,604x	-99.97%
6.86s	13%	2.94ms	<0.01%	2,333x	-99.96%

---

Before Merging

• Rebase after Use mixin instead of superclass for signature cops #183 is merged

Footnotes

1. No fancy benchmarking as the difference is large enough. Just ran rubocop --profile a couple times toggling between branches and grabbing results from Speedscope. ↩

[Morriar]

I think we should also enable this cop in the RBI config: https://github.com/Shopify/rubocop-sorbet/blob/main/config/rbi.yml#L195.

Which would mean allowing multiple signatures on the same def, so the next sibling could also be a sig.

[paracycle]

Yeah, agreed. Instead of next_sibling, we should still be looking for the next method/attr_ definition in a more performant way.

[sambostock]

The next_sibling approach already handled the case where there was an empty line between the last signature and method definition in a multiple signature case, but it didn't handle the case where there was an empty line between multiple signatures.

However, that was an easy change: the SignatureHelp module (replacing the SignatureCop class in #183) includes a signature? node pattern, which we can use to update the node pattern we use to check if the next_sibling is relevant to also consider signatures relevant.

In the interest of keeping this PR focused on the refactor and optimization, I've made those two changes in #188 instead:

• Teaches EmptyLineAfterSig to detect empty lines between multiple sigs
• Enables EmptyLineAfterSig in rbi.yml

[paracycle]

Ok, sounds good to me!