mirror of
https://github.com/logos-co/logos-cpp-sdk.git
synced 2026-08-31 09:41:06 +00:00
Dario Gabriel LipicarandClaude Opus 5
42eee59107
Completes the Qt half of the type mapping this branch started. A `type Foo { … }`
in a contract now generates a real struct in the client header, so a consumer
writes `Status s = client.makeStatus();` instead of digging fields out of a
QVariantMap. One LIDL type, one type per language.
lidlTypeToQt - Named -> the record's struct (was QVariant)
- [Record] -> QList<Record>, {tstr: Record} -> QMap<QString,
Record>. QVariantList CANNOT hold a record without
Q_DECLARE_METATYPE, and a typed list is the point.
client emitter - struct + inline ToVariant/FromVariant per record, emitted
before the class; conversions come after all structs so
records may reference each other. Recursive, so a field may
itself be [Status] or {tstr: bstr}.
- records pass by const&, decode on return, and convert at the
call site (sync and async)
bstr fields are QByteArray on purpose: logos-protocol's QVariant<->JSON
conversion already materialises the canonical {"_bytes": base64url} form as a
QByteArray and back, so the record conversions stay pure field mapping and binary
survives at any depth with no record-specific bytes handling.
Verified by COMPILING and RUNNING the generated code, not just asserting on text
— the string tests would not have caught either bug this found: [Record] first
mapped to QVariantList (appending a Status to it does not compile) and the decode
lambdas shadowed their accumulator. Extracted the emitted record block for a
contract with a nested record and a bytes field, compiled it against Qt6Core, and
round-tripped Batch -> QVariant -> Batch asserting items[0].port, the QByteArray
blob and the label all survive. Exit 0.
The LidlTypeToQt.NamedType expectation flips from "QVariant" to the struct name,
which is the behaviour change.
Tests: 169/169.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>