A -shared library's class is imported once, with the library's vtable

[ASDAlexander77]

This fixes two bugs in importing a class from a -shared library. I found them through the class import cycle (reference-path/import_cycle_class), whose -shared variant was left unregistered in #381. Neither bug needs a cycle.

1. The class was declared twice: redefinition of symbol named 'Base..new'.
A module whose export depends on a class of another module declares that class in its own __decls too. A derived class's base is the typical case, and that re-export is deliberate: a library holding only the derived module still has to describe the base. So an importer of a library holding both modules read the base twice. mlirGen(ClassLikeDeclaration) now skips a second, different declaration of an imported class that is already fully processed in this module. The new ClassInfo::processingDeclaration separates that case from the same declaration being generated again on a later pass.

2. The importer built the class's vtable in a different order from the library.
MLIRDeclarationPrinter::print(ClassInfo) printed all methods, then all accessors. The importer builds the vtable in the order it reads the members. So with get textContent() written before addText() in the source, the two slots were swapped, and the importer's n.addText("a") ran the getter: nothing was pushed, and reading childNodes[0] faulted. Each accessor half (get or set) is now printed where its function sits in classType->methods, which is the order the library built its vtable in. An accessor with no entry in the method list is still printed after it, as before.

Tests:

• reference-path-import-cycle-class is now registered through tslang_add_import_tests, so it runs static, -shared and -jit -shared.
• New shared-class-members/, all three tiers. A base class has an accessor before a method, and a setter between methods. A derived class in another module of the same library extends it. It hit both bugs before this change.

Results:

• The suite passes locally, 3016/3016, and the MLIRGenTests unit tests (which include the declaration printer) pass 144/144.
• I rebuilt DefaultLib (release, gc) with this compiler, and its tests pass 156/156 in both jit and compile modes. The local DefaultLib build was restored afterwards.

Not changed: with --export=all, a getter's local variables end up in __decls as @dllimport globals in a .f_Node.get_textContent namespace. The test runner doesn't pass that flag, and it's a separate issue.

🤖 Generated with Claude Code