new C() of a local class allocates in place instead of calling C..new

[ASDAlexander77]

Summary

• For a class defined in the module, new C() now emits what C..new's body would run: the ts.New and the vtable store. Before, it emitted a call to C..new.
• The ts.New carries __owned_result, as the call did. Under rc, NewOpLowering stores a count of 1 into the block header for such a ts.New. So the caller sees no ts.Retain, which is the same ownership shape the call had.
• Classes from elsewhere keep the C..new call. That covers declarations, imports, dynamic imports and @cpp classes. C..new is still generated for the vtable's .new slot and for other modules.
• Stack promotion no longer inlines C..new bodies, because every local new C() site is now a ts.New. newMethodOf, newMethodBody and the call branch of promote() are removed.
• Comments that described new C() as always a C..new call are updated.

Why no visible retain

A first version emitted ts.Retain after the ts.New. That broke -mm=own in two ways. The global-initializer check reported "takes a second reference" for let g = new H(). Two own-err tests also stopped reporting their expected errors. Making the +1 part of the allocation keeps the IR identical in ownership terms to the old call result.

ABI

There is no ABI change. The header layout and the count semantics seen by consumers are unchanged. The prebuilt DefaultLib and the CI LLVM artifact do not need rebuilding.

Testing

• The full Release suite passes, with 0 failures out of 4672.
• All 1469 rc and own run tests pass with -no-stack-promotion, which exercises the heap path. The 12 nonzero exits there are tests that expect an error by pass regex.
• A heap churn loop with promotion off allocated 10M objects under rc. Peak memory stayed at 3.8 MB and nothing crashed. The same loop also ran under own and gc.

🤖 Generated with Claude Code