Add gem --all --verify

[vinistock]

Motivation

If we change any aspect of gem generation in Tapioca, that gem's RBI can become stale even if it has not been upgraded. Currently, we only offer gem --verify, which will consider that the RBI is up to date if the version matches.

We were bitten by this in our own CI, when we broke gem RBI generation but didn't catch it because all gem versions matched.

By providing a gem --verify --all option, we can actually generate the RBI strings and check them against the RBI written in disk, to make sure that everything is indeed up to date.

Implementation

• Started accepting should_verify in execute
• Added a different flow for verifying
• Split compiling the gem RBIs from writing it to files, so that we can use the rbi_string for verification

Notes:

• Had to make the default_command public because I'm using a splat, which makes Sorbet force me to use T.unsafe, which is a public invocation

Tests

Copied all of the test scenarios from the regular gem --verify and adapted them.

[vinistock]

I added three new commits:

1. Ignore the type sigil when comparing RBI content. This is necessary because we change the sigil if the definitions conflict with a DSL file, which makes the comparison always fail with a false positive
2. Added a readme entry for the new flag combination
3. Re-generate all RBIs

After re-generating RBIs, we have some type checking errors. Almost all of them seem to be because we are no longer generating some includes and extends, that seem legitimate. For example, Thor's RBI:

class Thor
  # All of these were removed, but I think they are legitimate. And their absence causes type checking errors
  include ::Thor::Base
  include ::Thor::Invocation
  include ::Thor::Shell
  extend ::Thor::Base::ClassMethods
  extend ::Thor::Invocation::ClassMethods
end

Is this related to the recent work for proper mixin attribution? Any ideas?

[paracycle]

Is this related to the recent work for proper mixin attribution? Any ideas?

Yes, this is related to the recent work and will get fixed soon. In a nutshell, Thor gets loaded before we get a chance to install our mixin tracker and we never have a chance to register those includes, thus they get filtered out as not belonging to the gem.

[paracycle]

This should solve the problems with missing mixins: https://github.com/Shopify/tapioca/pull/1023

[vinistock]

We get different RBIs depending on the Ruby version. The command --verify --all passes locally, but fails on CI (differently for each Ruby).

I wonder if we'd be able to make this work. Maybe only for applications?

[paracycle]

We get different RBIs depending on the Ruby version. The command --verify --all passes locally, but fails on CI (differently for each Ruby).

I wonder if we'd be able to make this work. Maybe only for applications?

I think we should only run the verify step on the Ruby version we use for development. That should solve it.

[vinistock]

It doesn't quite do the trick, but I'm failing to see why.

[vinistock]

Closing this PR until we have a good approach for platform differences in RBIs.