Stop generating more methods than necessary

[paracycle]

Motivation

We used to treat methods that didn't have a source location the same as methods that explicitly were not defined in the current gem. That resulted in Tapioca creating more method definitions than necessary.

We would only skip method generation for a method if the constant it was on was an ignored type (i.e. a built-in type), so that we wouldn't keep redefining methods for built-in types. However, for all other types, especially types that come from other gems, we would just keep on generating all the methods regardless of if they were defined by this gem or not.

Moreover, the source location check was happening at the wrong location, before unwrapping the method signature. Thus, many methods with signatures would not be generated when the previous problem was fixed, since our code would see them as being defined in Sorbet runtime.

Implementation

The fix is to return a more fine-grained result from method_in_gem? which signals yes/no/don't-have-source-location. Based on that we can skip generating don't-have-source-location cases if they are for built-in types and totally ignore the methods that have a source location and are definitely not defined in the current gem.

Additionally, if we try to unwrap the method signature and we get an exception, that means the signature block raised an error. If we continue with the method as is, the source location checks would think the method definition does not belong in the gem (since the method is still wrapped), and we would thus skip the method generation. To avoid that, the signature_for method is now raising a custom exception to signal that exceptional case, so that we can at least continue generating "a" method definition.

Tests

Updated existing tests.

[vinistock]

When is the source_location equal to (eval)?

[paracycle]

Ah, forgot to mention that in the PR description, good catch. That happens when:

class Foo
  module_eval("def foo; end")
end

Foo.instance_method(:foo).source_location
# => ["(eval)", 1]

[paracycle]

Most usages of eval and friends do:

class Foo
  module_eval("def bar; end", __FILE__, __LINE__)
end

puts Foo.instance_method(:bar).source_location
# => ["foo.rb", 2]

though, so I would expect this to be an edge-case situation.

Still, I think erring on the side of caution for eval defined methods is the right call.