[mypyc] Transform object.__new__ inside __new__

[p-sawicki]

#19739 introduced support for compiling __new__ methods in native classes. Native classes differ internally from regular python types which results in TypeErrors being raised when object.__new__(cls) is called when cls is a native class.

To avoid making this call, super().__new__(cls) is transformed into a call to an internal setup function. I forgot to replicate this for calls to equivalent object.__new__(cls) calls so this PR fixes that. This introduced a regression because before my changes, __new__ methods with object.__new__(cls) were effectively ignored at runtime, and after my changes they started raising TypeErrors.

Note that these calls are left as-is outside of __new__ methods so it's still possible to trigger the TypeError but that is not a regression as this was the case before. For example this code:

class Test:
    pass

t = object.__new__(Test)

results in TypeError: object.__new__(Test) is not safe, use Test.__new__(). This differs from interpreted python but the error message is actually correct in that using Test.__new__(Test) instead works.

[BobTheBuidler]

you can add _64bit to the end of your test name to tell the 32-bit runner to skip it

ie testObjectDunderNew_64bit

[JukkaL]

Thanks for the updates! A few more minor things.

[JukkaL]

There could be a nested expression, e.g. [a, [b, c]] = ..., so this needs to be recursive.

[JukkaL]

Use double quotes around Python names for consistency, i.e. '... "{cls_arg}" in "__new__" method ...'.

[JukkaL]

Do we test anywhere that happens if there is str.__new__(cls) or str.__new__(str) or str.__new__(int)? Add run tests (or irbuild if they generate compile errors) for these if they don't exist (both within __new__ and outside).

[p-sawicki]

good idea, added the tests. turned out that we still need to check if translate_object_new was called for object.__new__() specifically because str.__new__() also triggered the transformation.

[JukkaL]

Thanks, looks good now!