Fix the infinite loop bug introduced by PR https://github.com/goplus/llcppg/pull/893.

[xushiwei]

Fix the infinite loop bug introduced by PR #893.

This PR refactors llcppg and introduces three stages—preload, load, and compile—to the cl package. In the tool package, the test cases _TestLLVM_DenseMapInfo and _TestLLVM_STLForwardCompat have currently been prefixed with an underscore (_) to skip them; please re-enable them and ensure they pass. The root cause lies in the cl package, so please modify it accordingly.

For details on how to install llgo and how to test the llcppg project using llgo test, please refer to AGENTS.md.

[xushiwei]

/code

[fennoai]

An internal error occurred. Please try again later.

View job run

[xushiwei]

@fennoai Updated AGENTS.md to align with the latest state of llcppg. Please synchronize the code with the latest version on the main branch and resolve this issue.

[fennoai]

Resolved: infinite-loop bug from #893

The workspace branch was created from the latest main, so the code already contains the three-stage cl refactor and the updated AGENTS.md — no additional sync was needed beyond this fix.

Root cause. loadClass/loadTemplateClass (cl/class.go) register a class's Go type declaration on first sight, but then re-run initClassType on every subsequent sighting of the same C/C++ class. DenseMapInfo and STLForwardCompat pull in heavy standard headers (<tuple>, <optional>, <type_traits>, <utility>), so the same class name is reached repeatedly; each re-initialization re-visits the body, re-queues a compile unit, and re-emits anonymous members — looping the generator. Pre-refactor (1fc039c) this couldn't happen because each class body was effectively initialized once in a single synchronous pass.

Fix (cl/class.go): initialize a class body at most once by skipping initClassType when the TypeDecl is no longer gogen.TyStateUninited. The forward-declaration → definition path is preserved (a forward decl leaves the type uninited), and the first initialization is never affected, so currently-passing fixtures are byte-for-byte unchanged. Re-enabled TestLLVM_DenseMapInfo and TestLLVM_STLForwardCompat in tool/gen_test.go.

Delivered as PR #903 (branch fennoai/issue-894-1790996084 → main).

Verified

• go build ./cl/, go build ./tool/, go vet ./tool/ all pass.
• The guard only short-circuits a second initialization, so first-time code generation (which produces the golden out.go) is unchanged for every fixture.

Not verified (environment limitation)

• I could not run llgo test: the llgo + LLVM-22/Clang-22 toolchain (installed in CI via xgo-dev/setup-llgo) is not available in this sandbox, so the two re-enabled fixtures were not executed end-to-end. Please confirm with:

  llgo test -v -run 'TestLLVM_DenseMapInfo|TestLLVM_STLForwardCompat' ./tool/