CJM v0.3.6

CJM v0.3.6 Release Notes

CJM v0.3.6 promotes the Tree-sitter C++ frontend from research spike to the
default production parser path for the current practical syntax surface.

This release does not expand the Metadata IR or generated JSON behavior. Its
purpose is to make the parser foundation stronger while preserving the v0.3
public workflow.

Highlights

• Uses a Tree-sitter-backed C++ frontend by default for CLI and CMake generation
• Preserves the existing SourceFileSyntax boundary into Semantic Analysis
• Keeps Tree-sitter implementation details inside the C++ frontend layer
• Adds parser parity coverage for the supported v0.3 syntax surface
• Fails closed for unsupported managed declarations that Tree-sitter can parse
  but CJM does not yet support semantically
• Registers Tree-sitter smoke and adapter tests in the normal test suite
• Keeps generated output compatible with existing golden tests

What Changed For Users

The user-facing workflow remains the same:

cjm generate --input model.hpp --output model.cjm.hpp

and:

cjm_generate(
  TARGET app
  HEADERS model.hpp
)

Users do not need the Tree-sitter CLI, Node.js, Rust, npm, Cargo, or Python to
build or use CJM.

Parser Behavior

CJM still accepts only its documented practical subset. Tree-sitter can parse
far more C++ than CJM supports, so the adapter is intentionally strict.

Supported managed fields continue to use same-line JSON metadata:

struct User {
    std::string name; // json:"name"
};

Unsupported managed forms are rejected instead of being silently misread.
Ordinary C++ members without CJM json:"..." metadata remain outside CJM's
managed model surface and are ignored by the adapter when they are not needed
for metadata extraction.

Verification

The release branch was verified with:

cmake --build build
ctest --test-dir build --output-on-failure

Expected result:

100% tests passed, 0 tests failed out of 21

Coverage includes:

• Tree-sitter adapter tests
• Tree-sitter smoke tests
• parser tests
• semantic tests
• generator golden tests
• CLI tests
• generated compile tests
• basic example build/run tests

Known Limitations

v0.3.6 remains a practical subset release.

Not yet supported:

• arbitrary JSON values
• std::variant
• std::any
• pointer fields
• polymorphism
• custom converters
• enum string mapping policies
• time and datetime mappings
• automatic header discovery
• full C++ grammar support
• multiline managed field declarations are not yet documented as supported
• private fields
• native JSON backend
• install/package distribution

Tag

Release tag:

v0.3.6

CJM v0.3.0

CJM v0.3.0 Release Notes

CJM v0.3.0 is the Practical Type Coverage release.

This release extends the v0.2 Practical Models surface with common JSON object
shapes, fixed-width numeric spellings, and stronger end-to-end verification.

Highlights

• Adds language-neutral Metadata IR support for string-keyed map fields
• Supports std::map<std::string, T> and
  std::unordered_map<std::string, T> where T is already in the supported
  practical mapping surface
• Rejects unsupported map key types before generation
• Preserves backend independence: the nlohmann backend consumes Metadata IR
  only and does not inspect C++ parser syntax
• Covers common fixed-width numeric spellings from <cstdint>
• Adds generated-code compile/run tests for expanded practical types
• Adds pipeline golden coverage for parser -> semantic -> Metadata IR ->
  nlohmann generation
• Adds CLI golden coverage for the v0.3 practical fixture

Supported v0.3 Additions

v0.3 builds on the v0.2 model surface.

Newly covered in v0.3:

• std::map<std::string, T>
• std::unordered_map<std::string, T>
• nested supported map value types
• std::int8_t
• std::int16_t
• std::int32_t
• std::int64_t
• std::uint8_t
• std::uint16_t
• std::uint32_t
• std::uint64_t
• composed supported practical types across maps, vectors, optionals, enums,
  aliases, and generated structs

Example:

namespace company::model {

using Sequence = std::uint64_t;

struct Detail {
    std::string source;  // json:"source"
    std::uint32_t shard; // json:"shard"
};

struct Event {
    Sequence sequence; // json:"sequence"
    std::int64_t timestamp_ns; // json:"timestamp_ns"
    Detail detail; // json:"detail"
    std::vector<std::string> tags; // json:"tags"
    std::map<std::string, std::vector<std::uint64_t>> buckets; // json:"buckets"
    std::optional<std::unordered_map<std::string, std::string>> attributes; // json:"attributes,omitempty"
};

} // namespace company::model

Map Semantics

CJM maps supported string-keyed C++ maps to JSON objects with dynamic string
keys.

Supported:

std::map<std::string, int>
std::unordered_map<std::string, std::string>
std::map<std::string, std::vector<std::uint64_t>>
std::optional<std::map<std::string, int>>

Unsupported map key types fail during semantic analysis:

std::map<int, std::string>

Map values must still be part of the documented practical mapping subset.

Verification

v0.3.0 was verified with both the normal build directory and a clean build
directory.

Normal test run:

ctest --test-dir build --output-on-failure

Expected result:

100% tests passed, 0 tests failed out of 19

Clean verification:

cmake -S . -B build-v03-verify
cmake --build build-v03-verify
ctest --test-dir build-v03-verify --output-on-failure

Expected result:

100% tests passed, 0 tests failed out of 19

Architecture dependency checks were also run:

rg -n "frontends/|backends/" src/core
rg -n "frontends/cxx" src/backends
rg -n "backends/nlohmann" src/frontends

These searches produced no architecture violations.

Known Limitations

v0.3.0 remains a documented practical subset.

Not yet supported:

• arbitrary JSON values
• std::variant
• std::any
• pointer fields
• polymorphism
• custom converters
• enum string mapping policies
• time and datetime mappings
• automatic header discovery
• full C++ grammar support
• multiline field declarations in the current handwritten parser
• production parser replacement
• install/package distribution
• cross-platform CI release gates

Frontend parser research, including Tree-sitter evaluation, is planned for
v0.3.5.

Dogfooding and adoption documentation are planned after v0.3.0 so that
downstream projects can consume a real release tag.

Tag

Release tag:

v0.3.0

The tag should point to the v0.3.0 release commit on main.