Refactor trampoline setup

[Otto-AA]

This PR makes following changes:

• use a @_mutmut_mutated decorator as a trampoline. This allows using *args and **kwargs for default args, while
  keeping dynamic and static type signature the same (fixes Fix default argument mutation #477 )
• instead of generating the trampoline as a string, we now import it from mutmut
• unified handling of normal class methods, @staticmethod, @classmethod
  and enums (always put dictionary outside the class body, and methods inside class body)
• stack frame counting only includes source_paths code (fixes Only count user-code frames for max_stack_depth #378 )

The test_mutation_regression.py test shows how the mutation changed. Now it's like this:

class Adder:
  def add(self, value):
    return self.amount+ value

becomes

from mutmut.mutation.trampoline import wrap_in_trampoline as _mutmut_mutated, MutantDict

mutants_xǁAdderǁadd__mutmut: MutantDict = {}  # type: ignore

class Adder:
    @_mutmut_mutated(mutants_xǁAdderǁadd__mutmut)
    def add(self, value):
        return self.amount + value # <- this implementation here is not used; only kept for type checking

    def xǁAdderǁadd__mutmut_orig(self, value):
        return self.amount + value

    def xǁAdderǁadd__mutmut_1(self, value):
        return self.amount - value

mutants_xǁAdderǁadd__mutmut['_mutmut_orig'] = Adder.xǁAdderǁadd__mutmut_orig # type: ignore # mutmut generated
mutants_xǁAdderǁadd__mutmut['xǁAdderǁadd__mutmut_1'] = Adder.xǁAdderǁadd__mutmut_1 # type: ignore # mutmut generated

Overall I'm pretty happy with this design, as it works for everything we support currently (normal class methods, @staticmethod, @classmethod and enum). For the @classmethod, we need to have some special handling s.t. we call the method bound to the cls class (see is_classmethod in trampoline.py). Apart from that the trampoline only passes the args and kwargs to the appropriate original/mutated method.

@nicklafleur As you already know this part of the code, happy for feedback. Also if something you want to build on top of this would not work with this design, let me know :)

And the runtime tests are pretty handy ❤️

[nicklafleur]

one extremely minor nit, otherwise I really really like the design of this, reads much more clean than what I came up with!

It's not immediately obvious to me where the stack tracking will fit in for the cache invalidation, but I'm sure that there's some options as far as reflection goes in the decorator that we can work with so it should be more than possible just a matter of rebasing and giving it a shot (I should have time to try it out this week).

[nicklafleur]

Suggested change

	async def async_get_all() -> AsyncGenerator["Color", None]:
	async def async_get_all() -> AsyncGenerator[Color, None]:

The unquoted Color here is a meaningful test signal for handling unquoted py3.10 forward references

[Otto-AA]

Only Python 3.14+ supports unquoted forward references, so I don't think we need to support this for Python 3.10? Previously, running mutmut with this code worked, because we manually quoted the references and never executed the unquoted forward references. But running pytest in the e2e_projects/my_lib on main with python 3.10 raises following error:

tests/test_my_lib.py:3: in <module>
    from my_lib import *
src/my_lib/__init__.py:152: in <module>
    class Color(Enum):
src/my_lib/__init__.py:162: in Color
    async def async_get_all() -> AsyncGenerator[Color, None]:
E   NameError: name 'Color' is not defined

i.e. it's invalid code for python 3.10, only mutmut made it valid while mutating the code.

But it's a good point that we should test for forward references in classes, I've added them for the python 3.14+ tests: c720999

[Otto-AA]

I'll merge it as I think the py 3.14 tests should cover this. If I missed something, feel free to ping me or add the test case afterwards.

[Otto-AA]

It's not immediately obvious to me where the stack tracking will fit in for the cache invalidation, but I'm sure that there's some options as far as reflection goes in the decorator that we can work with so it should be more than possible just a matter of rebasing and giving it a shot (I should have time to try it out this week).

I'd see two possibilities:

• refactor the trampoline to pass the function name to the record_trampoline_hit function (likely decorated_func.__name__ or orig_func.__name__)
• use inspect.currentframe().f_code.co_name or something similar (https://docs.python.org/3/reference/datamodel.html#code-objects)

Both seem reasonable approaches to me, the first one maybe a bit simpler.