[REG 2.103.0] GC never finalizes a class whose only destructors are field destructors #23979

A class with no ~this() (or any base class) whose fields have destructors is allocated without BlkAttr.FINALIZE, so the GC never runs the field destructors, either on collection or at program exit. destroy and scope work correctly. Adding an empty ~this() {} to the class works around it.

import core.memory : GC;

__gshared int finalized;

struct R {
	int x;
	~this() {
		if (x) ++finalized;
	}
}

// no ~this(): only a field destructor
class C {
	R r = R(1);
}

void main() {
	assert(GC.getAttr(cast(void*) new C) & GC.BlkAttr.FINALIZE); // fails
	foreach (i; 0 .. 100) new C;
	GC.collect();
	assert(finalized > 0); // also fails: no C is ever finalized (comment out the first assert)
}

Fails with DMD64 D Compiler v2.113.0 and GDC 14.2 (frontend 2.108). Passes with LDC 1.43.0, which lowers new to its own _d_allocclass(ClassInfo).

Cause: core.lifetime._d_newclassT sets FINALIZE only if __traits(hasMember, T, "__dtor"). __dtor exists only for a user-declared destructor; a class whose destruction comes only from its fields has just __xdtor. typeid(C).destructor is set and ClassFlags.hasDtor is set, so the ClassInfo is correct.

Regression: This started in 2.103.0 with #14837, which turned _d_newclass into the _d_newclassT template. The old function checked ClassFlags.hasDtor, which includes field destructors; the template only checks for __dtor. I confirmed this by building both releases from their tags: 2.102.2 finalizes the class and 2.103.0 does not. GDC shows the same split between GDC 12 and GDC 13.

Related:

• [REG 2.103] Class objects without explicit pointers are scanned by the GC #22599: same origin, other flag. _d_newclassT also gets NO_SCAN wrong for pointer-free classes (still reproduces on 2.113).
• Bugzilla 24882: similar regression from the same change (lost COM class check).
• [REG 2.096] Double destruction of new'ed aggregates since -preview=dtorfields became the default #18037: once these classes are finalized again, a throwing constructor double-destroys its fields (constructor cleanup, then GC), as already happens today for classes with ~this() on DMD and for all classes on LDC.
• Field destructor not called for extern(C++) class without explicit destructor #22942: same symptom on the destroy path for extern(C++) classes; separate cause, fixed in Fix #22709 - Use of extern(C++) destructor is hidden #22931.

I have a patch ready, tho im not 100% sure its exactly whats needed.