HasClassAttribute(AClass, AAttrClass) was unreliable on the native backend:
- The call was never emitted. The builtin had no native lowering, so it fell
through to a generic path that left the first metaclass's typeinfo address in
%rax and read its low byte as the Boolean result — a layout-dependent false
positive (a plain class reported as having an attribute).
- Even with the call, the attribute table was missing: native typeinfo
hardcoded slot 7 (attrs) to nil, so a [Threaded]-marked class reported False.
Fixes (blaise.codegen.native.x86_64.pas):
- Add a native lowering for the HasClassAttribute builtin (gated on
FC.IsBuiltinHasClassAttr): evaluate both metaclass args to typeinfo pointers
in %rdi/%rsi, call _HasClassAttribute, normalise %al to 0/1. Mirrors the
QBE backend.
- Emit the class attribute RTTI table (count + one typeinfo pointer per
attribute) as attrs_<Class> and reference it from typeinfo slot 7, nil when
the class has no attributes. Mirrors the QBE backend's attrs_<Class>.
This is what blaise.testing's runner uses to decide [Threaded] subprocess
dispatch; the false positive forked non-threaded suites and crashed them.
e2e test in cp.test.e2e.gaps (AssertRTLRunsOnAll, both backends): a plain
TTestCase reports False, a [Threaded] one reports True. Full suite OK (3739);
all four fixpoints pass on both build paths.
6d46af93de