Add debug object trace writer

[Yu-zh]

Summary

• add @debug.debug_object as a debug-only optional object-template writer
• compile it to None in release mode so <? skips evaluating debug fields
• re-export debug_object from prelude

Example:

@debug.debug_object <? { "value": value }

Known issues / follow-ups

1. Re-entrancy: debug_object is a package-level optional writer, so nested use can reuse the same buffer. A nested debug_object <? ... inside a field expression can interfere with the outer trace.
2. Build system artifact mode: currently the bundled core is built under release mode and only the release-mode artifacts are used. This needs a build-system-side fix so moonbitlang/core artifacts from both release mode and debug mode can be used.

Tests

• moon fmt
• moon check debug
• moon check --release debug
• moon test debug
• moon test --release debug
• moon check prelude
• moon test prelude
• moon info
• moon check

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 098f06ee13

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Avoid reusing one mutable debug writer

In debug builds this exposes a single package-level DebugObject with a mutable buffer, so any field expression that also logs via debug_object <? ... re-enters the same writer: the inner write_object_begin resets the outer buffer and the inner write_object_end resets first, causing the outer trace to lose or split fields. This affects nested helper calls that use the prelude-exported debug_object; the writer needs per-invocation state (or a stack) rather than a shared singleton.

Useful? React with 👍 / 👎.

[coveralls]

Coverage Report for CI Build 4652

Coverage decreased (-0.003%) to 94.244%

Details

• Coverage decreased (-0.003%) from the base build.
• Patch coverage: 1 uncovered change across 1 file (8 of 9 lines covered, 88.89%).
• 1 coverage regression across 1 file.

Uncovered Changes

File	Changed	Covered	%
debug/trace.mbt	9	8	88.89%

Coverage Regressions

1 previously-covered line in 1 file lost coverage.

File	Lines Losing Coverage	Coverage
builtin/autoloc.mbt	1	77.78%

---

Coverage Stats

Relevant Lines:	15878
Covered Lines:	14964
Line Coverage:	94.24%
Coverage Strength:	207050.83 hits per line

---

💛 - Coveralls