[sferik]

memosa memoizes a method by prepending a MemosaMethods module that defines a wrapper of the same name, which calls super. When mutant asks the class for that method, it gets the wrapper back, and the wrapper's source location points into memosa itself. Mutant parses memosa.rb, finds no matching def, and silently drops the method. No warning, it just never becomes a subject.

For example:

class Calc
  extend Memosa

  def initialize(value)
    @value = value
  end

  memoize def double
    @value * 2
  end

  memoize private def secret
    @value + 1
  end

  def reveal
    secret
  end
end

On main, mutant finds 2 subjects here (initialize and reveal) and never touches double or secret. With this patch it finds all 4, and all 37 mutations are killed by a small spec, which also shows the mutated code really runs behind memosa's wrapper.

The fix is in Matcher::Methods: after looking up a method, follow super_method until the owner is the scope itself. The original method is still defined on the class, so mutations replace it and the prepended wrapper keeps working around them (caching included). Since it lives in the shared matcher, it covers singleton methods too.

The fork linked in the issue special-cased memosa, but nothing here is memosa specific, so mutant doesn't need to know about it. Anything that wraps methods with prepend (instrumentation, other memoizers) gets the same treatment, and mutating the method on the class while leaving the wrapper in place seems like the right behavior for all of them.

I checked the case where a subclass changes the visibility of an inherited method (private :foo), since that creates a method entry without a body. Ruby reports the subclass as the owner, so the loop stops right away.