[mypyc] Fix reference leak when setting unboxed refcounted attrs

[Tombana]

I ran into this memory leak which can reproduced with:

from dataclasses import dataclass

@dataclass
class MyClass:
    v: int

c = MyClass(1 << 70)

This PR adds a fix and a test that fails without the fix. I am no expert on mypyc internals, so I asked Claude Code to fix this bug. It is a one-line change so I believe it will be easy to review.
From quick inspection it seems that the rest of the code has fewer comments than what Claude wrote, so if you prefer, I'll remove the verbose comment that this PR adds. Similarly for the test code, it can be shortened if wanted.

Long explanation from Claude code

Description

A native attribute setter generated by mypyc over-increfs the stored value when
the attribute has a refcounted unboxed type — most importantly int
(CPyTagged), and also tuples with refcounted items.

For an unboxed type, generate_setter emitted:

tmp = CPyTagged_FromObject(value);  // already creates a NEW (owned) reference
CPyTagged_INCREF(tmp);              // ...and then takes a second one
self->_v = tmp;

CPyTagged_FromObject already increfs in the heap-boxed case, so the setter
takes two references while the deallocator releases only one — leaking one
reference on every set through the setter. The other two branches of
generate_setter (object and the emit_cast path) are correct because they
produce a borrowed value and rely on the single emit_inc_ref to take
ownership; only the unboxed branch was inconsistent.

Why this shows up with dataclasses

This is reached whenever an attribute is set from interpreted code. The clearest
real-world case is the init that the stdlib dataclasses module
synthesizes for a mypyc-compiled @DataClass: its self.v = v runs as
interpreted code and goes through the generated descriptor setter. So every
constructed instance of a compiled dataclass with a heap-boxed int field
(value ≥ 2**62) leaked one PyLong — silent, unbounded growth in long-lived
programs that build many such objects (e.g. 64-bit ids).

It does not depend on slots, frozen, eq, field count, or field
position; a hand-written native init is unaffected because it stores via
SetAttr rather than the descriptor. Small (inline-tagged) ints, floats, and
object-typed fields are also unaffected since they aren't refcounted through
this path.

Reproducer

from dataclasses import dataclass
import sys

@dataclass
class C:
    v: int

big = 1 << 70                  # heap-boxed int (>= 2**62), so it is refcounted
base = sys.getrefcount(big)
xs = [C(big) for _ in range(1000)]
del xs
print(sys.getrefcount(big) - base)   # before: 1000   after: 0

Fix

Unbox with borrow=True in the setter's unboxed branch, so all three branches
of generate_setter produce a borrowed value and the single emit_inc_ref
takes exactly one owned reference. borrow=True is a no-op for non-refcounted
unboxed types (float, fixed-width ints, bool) and is propagated correctly
through RTuple unboxing, which fixes the analogous leak for tuple-typed
attributes too.

Tests

Added testNativeAttrSetterRefcountLeak to mypyc/test-data/run-classes.test,
covering a boxed-int dataclass field, an unboxed Tuple[int, int] field, and
setter re-assignment. It fails before the fix (expected 100 live refs, got 200) and passes after.

[p-sawicki]

thanks!