mirror of
https://github.com/logos-co/logos-cpp-sdk.git
synced 2026-08-31 01:31:10 +00:00
1be71bbbeb75ae854babe40eeeabc24ea93d2cff
125
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Dario Gabriel LipicarandClaude Opus 5
|
1be71bbbeb |
feat(sdk): make the by-name call path a supported API
The dynamic (by-name) invoke path already existed and was already ungated at every layer — lp_client_create / lp_invoke in the C ABI, logos::LpClient above it, and the Qt client above that. Nothing checked a host service; there was no gate to open. What was missing was the ERGONOMICS, which is what turned a supported capability into something callers reached around the umbrella to get. Three additive pieces, no gate touched: 1. LogosModuleContext::moduleName() — the module's own registry name, i.e. the origin it authenticates as. The typed wrappers bake their origin in at codegen time; a by-name call has to state one, and a wrong origin authenticates as nobody and fails far from the call site. Set through a NEW `_logosCoreSetModuleName_`, deliberately not a fourth parameter on `_logosCoreSetContext_`: every generated provider calls that signature, so widening it would break each one until regenerated, for a value the generator knows statically. Set before the context, so moduleName() is live inside onContextReady(). 2. LogosModules::dynamic(target) on the origin-bound umbrella — the untyped client, with the origin baked in exactly as the typed members' is, and cached per target because LpClient owns a connection. The typed members over metadata.json#dependencies stay the ordinary way to call another module; this is for the cases whose target is a runtime value (a proxy, a router). 3. LpClient::getMethods() over the already-exported lp_get_methods. Invoke without introspect is guessing — a caller that cannot ask what exists can only hardcode, and a wrong guess fails at runtime like a typo. Verified: #default builds, and both checks pass (tests, generator-cli). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Dario Gabriel LipicarandClaude Opus 5
|
1afcf46f4d |
refactor(cpp-generator): merge legacy/ into the generator, dropping its dead half
`legacy/` was never a library with an API surface. Two files, 475 lines, exactly
one exported symbol — `int legacy_main(int, char**)` — with every other
definition `static`, compiled INTO logos-cpp-generator and reached by fallthrough
at the end of main(). So there was nothing to keep separate: it is one mode of
this binary, and it now lives beside the others as plugin_introspect.{cpp,h}
behind `runPluginIntrospectMode()`, named for what it does.
Deleting it was never an option — that premise was checked and refused earlier.
`--general-only` alone has ~10 live callers across 7 repos including the central
module path (buildPlugin.nix:206,211, buildHeaders.nix:221,
LogosModule.cmake:423). The mode is load-bearing; only its packaging was wrong.
110 lines go with the move, all genuinely unreferenced:
* cppStringEscape — zero callers anywhere.
* writeUmbrellaHeader / writeUmbrellaSource and the `if (!moduleOnly)` block
that called them. This is the real prize: a SECOND, directory-SCRAPING
implementation of logos_sdk.{h,cpp}, unreachable in practice because
generate-module-headers.sh:60 always passes --module-only. generator_lib's
deps-driven makeUmbrella*FromDeps is now the only umbrella emitter, so the
two cannot drift.
* a dead `QJsonDocument doc(methods);` and its commented-out use.
With the block gone, `--module-only` suppresses nothing, so the parameter and
its plumbing go too. The FLAG stays tolerated rather than rejected, because
generate-module-headers.sh passes it unconditionally — a comment at the old
parse site says so.
Verified: #default builds, and both checks pass — `generator-cli` (which
exercises the CLI surface, including --general-only) and `tests`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Dario Gabriel LipicarandClaude Opus 5
|
d27927aba5 |
docs(generator): stop pointing callers at a flag that no longer exists
--backend qt is deleted from logos-qt-generator, and this repo was still signposting it. main.cpp's refusal said "Use it for --backend qt", and the usage text advertised --lidl … --backend qt and --from-header … --backend qt. Those now point at nothing — the exact failure the deletion removes, one repo over. The refusal names the real replacement chain instead: --backend cdylib here, then logos-qt-host-generator --backend cdylib for Qt-plugin packaging. docs/project.md's "Provider Generation" section documented three emitters that no longer exist; rewritten to state the seam and the two-step pipeline. docs/spec.md's dataflow diagram showed <name>_qt_glue.h / <name>_dispatch.cpp as outputs; the diagram is corrected and the sections describing that shape are marked historical rather than deleted, because the onInit wiring they document still applies to the cdylib glue. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Dario Gabriel LipicarandClaude Opus 5
|
620f2e184c |
feat(generator): a Qt-typed umbrella that needs no LogosAPI
Splits a consumer's TYPE SURFACE from its TRANSPORT. Until now the qt umbrella
was `explicit LogosModules(LogosAPI* api)` while the lp one was default-
constructible, so "Qt types" implicitly meant "has a LogosAPI" — and a cdylib
module, whose provider surface is the std logos_module_impl.h C ABI and which
holds no LogosAPI anywhere, could not have Qt-typed dependency wrappers at all.
Its generated glue emits `new LogosModules()` unconditionally
(lidl_gen_cdylib.cpp:693), so the combination did not merely misbehave, it did
not compile.
That was a codegen choice, not a law: the wrapper bodies already run over lp_*.
`--binding api|origin` selects it, defaulting to `api`. A second enum rather
than a third ApiStyle value, deliberately: ApiStyle names the type surface and
is switched on by six emitters (makeHeader/makeSource/returnTypeFor/
paramTypeFor/toWireFor/fromWireFor); a "Qt types, explicit origin" member would
force all six to answer a transport question whose honest answer is "same as
Qt" every time. ApiStyle::Lp ignores the new axis — lp is origin-bound by
construction — and that is asserted rather than assumed.
The emitted umbrella bakes metadata.json#name as the origin literal:
LogosModules() : test_fullapi_cpp(QStringLiteral("test_fullapi_qtproxy")) {}
FullApi bind_full_api(const QString& moduleName) {
return FullApi(QStringLiteral("test_fullapi_qtproxy"), moduleName); }
Origin is the CONSUMER's own name and target is the dep — origin first in both
bind_ overloads. This is the load-bearing property: LpBridge::forTarget derives
origin from `api->moduleName()`, and reusing it silently gives a consumer the
caller's identity, which has already preserved a privilege escalation once in
this tree. An empty metadata name is refused at the CLI (exit 6, naming the
file) and emits `#error` in the header: a module that cannot state its identity
must not compile, and must never be handed a blank or borrowed one.
Verified additive on 172 real metadata.json x 2 api-styles = 344 runs, all
producing output, byte-identical old binary vs new. Mutation control: swapping
bind_<iface>'s (origin, moduleName) to (moduleName, origin) fails the suite at
MakeUmbrellaTest.QtExplicitOriginStatesTheConsumersOwnNameEverywhere. 281 -> 286
tests.
Framing worth keeping: the origin is SELF-ASSERTED from the module's own
metadata and is not attested by the transport. That is not a regression —
`api->moduleName()` is equally process-stated — but "explicit origin" means the
module names itself, not that the host vouches for the name.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Dario Gabriel LipicarandClaude Opus 5
|
2ef1c25929 |
feat(sdk): split the SDK by capability, and add the host façade
Host, module-consumer and module-provider are three distinct capabilities. The
SDK exposed them as one target, so a program linked all three regardless of
what it was. Each now gets its own INTERFACE target:
::common logos_json.h, logos_result.h
::consumer logos_lp_client.h, logos_async_result.h
::provider logos_module_context.h, logos_host_services.h
::host logos_host_core.h (new)
`logos_headers` stays as an umbrella over all four, so the ~70 existing
consumers are unaffected — logos_module_context.h alone has 66. Migrate to the
narrow targets when touching a repo; additive first, removal second.
NOTE the misnomer the split exposes: `logos_host_services.h` is MODULE-side
despite its name — it is the veneer a privileged module uses for services the
host granted it — so it belongs to ::provider, not ::host. Renaming it touches
9 files across 5 repos, so it is left for a change that can carry that cascade.
── logos_host_core.h ───────────────────────────────────────────────────────
`logos::host::LogosCore`, a plain RAII wrapper over liblogos' logos_core_* C
API, for the four programs that stand up a core (basecamp, logoscore-cli,
standalone-app, module-viewer). They currently open-code the same calls, and
basecamp had already grown a private wrapper for them.
It is deliberately an ORDINARY class — no codegen, no injection seam, no
void*. LogosModuleContext needs `_logosCoreSetContext_`, SFINAE `maybeSet*`
helpers and a void* round-trip because a module impl is user-authored but
FRAMEWORK-instantiated. A host is main(): it constructs this itself. For the
same reason there is no `modules()` here — the host holds its own LogosModules
from its own generated logos_sdk.h, so this header needs no generated type.
What it earns, each tied to a measured hazard:
* OWNERSHIP. liblogos allocates its char**/char* returns with new[], so
`delete[]` is correct and free() is undefined behaviour. That rule lived in
a comment in one repo's .cpp; it is now in one place.
* ORDERING. Three setters must precede logos_core_start(), stated only in
comments in logos_core.h. They are constructor arguments here, so the
illegal order is not expressible.
* SHAPE. logos_core_get_module_stats() takes no module name and returns one
blob for every module; stats(name) does that parse once.
The logos_core_* ABI is re-declared rather than included: logos-liblogos
depends on logos-cpp-sdk, so including its header would invert the graph. Every
host already hand-declares it; this makes it one declaration instead of four.
15 tests, 281/281 suite total. They define the extern "C" ABI themselves and
allocate exactly as liblogos does, so the ownership rules are exercised rather
than asserted; the ordering test records call order and pins start() as last.
Also fixes a real gap: nix/include.nix carries its own header list, separate
from cpp/CMakeLists.txt's install(FILES), so a new header silently did not ship
in the export layout.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Dario Gabriel LipicarandClaude Opus 5
|
5a0c3ed93a |
refactor(generator): the umbrella emitter leaves legacy/, and gets its own mode
`cpp-generator/legacy/` held four things and only one was legacy. The shared
emitter library was misfiled there: `generator_lib.{h,cpp}` is already consumed
by the MODERN `experimental/lidl_gen_client.h` and by all 11 tests under
tests/generator/. `lidl_to_json.{h,cpp}` likewise. Both are now
`cpp-generator/`; `legacy/` is down to `main.cpp` + `legacy_main.h`.
The logos_sdk umbrella (`struct LogosModules`) is not legacy either — it is the
CURRENT typed-dependency surface. `LogosModuleContext::modules()` returns it,
so every universal module that calls a declared dependency goes through it, and
LogosModule.cmake runs `--general-only` for every module build. Yet the only
code that could emit it lived inside the directory the plan wants deleted.
So `cpp-generator/main.cpp` gains `--umbrella`, with `--general-only` routed to
the same implementation and dispatched before the fall-through to legacy_main.
The deps-driven emission needed no rewriting: `makeUmbrella{Header,Source}
FromDeps` were already in generator_lib, and legacy/main.cpp merely wrapped
them in file I/O. -352 lines from legacy/main.cpp (827 -> 475), including the
interface-wrapper helpers that only that branch used.
`--general-only` keeps working identically, because LogosModule.cmake and
logos-basecamp both call it. The alias is guarded on `--metadata`, since
`--general-only` was never a standalone mode — without metadata it fell through
and reported the flag as a missing plugin path, and it still does.
The scraping `writeUmbrellaHeader`/`writeUmbrellaSource` are untouched: they
belong to `generateFromPlugin`, the QPluginLoader introspection path, and die
with it.
Verified byte-identical, which is the whole claim of a relocation. An
adversarial pass built its own pre- and post-change binaries and diffed the
emitted `logos_sdk.{h,cpp}` across 12 real metadata.json files x {qt,lp} x
{--general-only,--umbrella}: 48/48 identical, stdout/stderr/exit included, with
a positive control (qt vs lp) confirming the harness can see a difference. Real
modules then built through logos-module-builder against both binaries with
`diff -r` empty, including the compiled plugin. 266/266 tests pass, and the
pre-change tree also reports 266, so no test was silently dropped.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Dario Gabriel LipicarandClaude Opus 5
|
c0cba910ae |
refactor(generator): remove --module-dir, and the two dead files it documented
--module-dir walked a directory of BUILT plugins and generated one consumer
wrapper per dependency by dlopen'ing each and reading its QMetaObject. Every
wrapper now comes from a contract instead -- `--general-only` with one
`--dep <name>=<name>.lidl` per dependency -- which builds no dependency plugin
and, unlike introspection, works under cross-compilation.
It is REFUSED rather than ignored, mirroring --provider-header right below it.
Falling through to the dependency LISTING would have exited 0 having generated
nothing: the exact shape that lets a stale caller look green while shipping a
module with no typed API.
No nix build changes as a result -- the flag had no caller left in any of them,
so a store-path diff would be empty either way and would prove nothing. The
only observable difference is what the binary does when handed the flag, so
that is what the new `generator-cli` check asserts, by EXIT CODE:
OK: control - --metadata alone exits 0 and lists dependencies
OK: --module-dir exits non-zero (status=2)
OK: --module-dir fails with the removal diagnostic
OK: --general-only still emits the umbrella
The control matters: without it a non-zero exit could equally mean the binary
is broken. It runs against an EXISTING modules directory too, because the old
code only errored when that directory was missing.
Also deleted, both genuinely dead:
* cpp/compile.sh -- compiles logos_api.cpp, module_proxy.cpp, token_manager.cpp
and six headers, NONE of which exist in this repo any more (they moved to
logos-protocol / logos-qt-host in the host split). The script cannot run.
* docs/docs.md -- 789 lines with zero inbound references anywhere in the
workspace, documenting --module-dir and a cpp/ layout that is gone.
cpp-generator/compile.sh is KEPT: logos-module-builder's LogosModule.cmake:404
still invokes it (`add_custom_target(cpp_generator_build ...)`) on the
LOGOS_CPP_SDK_IS_SOURCE branch, and it builds into exactly the
LOGOS_DEPS_ROOT/build/cpp-generator path that file then reads.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Dario Gabriel LipicarandClaude Opus 5
|
a04b27888e |
chore(deps): rev-pin logos-protocol at c8bab12 (the trust-root surface)
logos_host_services.h is a veneer over lp_token_keys / lp_inform_module_token_to / lp_grant_host_services, which landed on logos-protocol's feat/per-client-token-store branch and are NOT on its master — master is still LOGOS_PROTOCOL_VERSION_MINOR 2, so the `tests` check could not compile against the previously locked 03842db. Rev-pinned in the URL rather than left master-tracking, because `nix flake update` cannot reach a commit that is not on the tracked branch. Re-point at master once that branch merges. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Dario Gabriel LipicarandClaude Opus 5
|
cefd5aec21 |
docs: point logos_async_result.h at the one LogosModule.cmake
The comment named "logos-plugin-qt/cmake/LogosModule.cmake and its module-builder twin". There is no twin any more: logos-plugin-qt's copy is deleted and the file exists once, in logos-module-builder. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Dario Gabriel LipicarandClaude Opus 5
|
4ddcce7038 |
fix(generator): guard the grant export on the protocol MINOR that added it
The emitted logos_module_grant_host_services calls lp_grant_host_services, which logos-protocol only gained at MINOR 3. A module built against an older protocol therefore failed to compile in GENERATED code its author never wrote. Found by giving logos-template-module a standard flake: its own lock resolves protocol master, and the build died on `use of undeclared identifier`. Guarded on LOGOS_PROTOCOL_VERSION_MINOR >= 3. A module built against 0.2 has no grant entry point at all, which is the same fail-closed state as never being granted. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Dario Gabriel LipicarandClaude Opus 5
|
2277981777 |
feat(generator): emit logos_module_grant_host_services in the cdylib exports
Completes the C1 codegen half. A3 declared this entry point in logos_module_impl.h and documented that the grant MUST cross the C ABI, but the generator never emitted it, so nothing could open a module's gates. The body forwards to lp_grant_host_services in the MODULE's own image, which is the entire point. Verified that premise on a real built module rather than taking it from the header comment: test_basic_module_cpp_plugin.dylib DEFINES 25 lp_* symbols and imports zero — logos-protocol is statically linked into each plugin, so the module's gate state really is its own, and a grant recorded only in the host would leave lp_token_keys() returning null forever. That failure is silent: null is indistinguishable from an empty token store. Emitted unconditionally rather than behind a codegen flag. Which modules are privileged is the host's decision — it pushes nothing to an ordinary module — and lp_grant_host_services validates the names and fails closed, so a per-module flag would only add a second place for declaration and capability to disagree. The comment states the boundary honestly: this is a declaration-and-audit mechanism, NOT a defence against a hostile module. The cdylib links logos-protocol, so its own code can call lp_grant_host_services() directly and self-grant. What the gate buys is that the privilege is explicit, greppable and off by default. Isolation between modules rests on process separation, the auth token, and the target's allowedCallers. Three tests, one per property that could regress independently: the export exists; its body actually forwards (a stub returning 0 would make every host push look successful while both gates stayed shut); and it is emitted for an ordinary module too, not only for privileged ones. Confirmed in the built artifact: nm on a real universal module lists _logos_module_grant_host_services alongside the other seven module-impl exports. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Dario Gabriel LipicarandClaude Opus 5
|
b9d7641fae |
feat(sdk): logos_host_services.h — the C++ veneer over the privileged surface
Phase C1. A Qt-free, header-only wrapper over the three trust-root lp_* calls A3 added, so capability_module can become an ordinary universal module instead of a hand-written Qt plugin reaching into TokenManager directly. Deliberately FREE FUNCTIONS, not a LogosModuleContext seam as the plan sketched. The grant is process-global per IMAGE (host binary and module cdylib each link their own logos-protocol, so each has its own grant state and its own TokenManager), so the gate lives in the caller's own image and there is nothing per-instance to inject; a context seam would imply the privilege is a property of one impl object, which it is not. It is also markedly cheaper: a seam would need a new module-impl C ABI export plus lockstep changes in BOTH codegen paths (the Qt provider glue and the cdylib wrapper). constantTimeEquals lives here rather than in each caller: the natural spelling (a == b) leaks the matching-prefix length through timing, and a trust root comparing tokens with == is the exact bug this file exists to prevent. Ported from capability_module's own implementation to std::string. Two things the tests caught that reading had not: * lp_inform_module_token_to takes SIX arguments (client, auth_token, origin_module, module_name, token, timeout_ms), not the three I first wrote. The wrapper now mirrors it exactly, with the protocol's own default-timeout semantics documented. * sdk_tests compiles against logos_headers alone, which carries no protocol include path. It now resolves logos_protocol.h from LOGOS_PROTOCOL_ROOT, accepting either the source layout (cpp/) or a package layout (include/) and failing loudly on neither, rather than hard-coding the one in use today. The suite deliberately does NOT link logos-protocol: the lp_*-calling wrappers are `inline` and never ODR-used by these tests, so no protocol symbol is referenced. That is itself the assertion — the veneer must not drag the protocol library into a header-only consumer. A future test that calls one will fail to LINK rather than silently pull it in. Also documents a real gap found while writing it: lp_token_get performs NO host-service check, so "token_registry" gates ENUMERATION only. The plan claims that service covers `lp_token_get(any)`; it does not. Flagged at the call site rather than papered over — if lookup should be gated, the gate belongs in lp_token_get. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Dario Gabriel LipicarandClaude Opus 5
|
1017aa56b9 |
feat(generator): remove --provider-header (interface: "provider")
Every provider now goes through the module-impl C ABI, so the LOGOS_METHOD dispatch path is gone: parseProviderHeader, generateProviderDispatch, ParsedMethod and the joinDocLines helper only it used (~300 lines), plus the test that covered it. `toQVariantConversion` is NOT removed — it is shared with live emitters — and its test stays. The flag is REFUSED rather than dropped. Without that, `--provider-header x.h` falls through to the plugin-path branch, which reads the flag itself as a plugin path and reports "Plugin file does not exist: --provider-header" — a missing-file error for what is really a retired mode. It now exits 2 with a message pointing at interface: "universal". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
e3744fb84c |
feat(windows): add an x86_64-windows cross target (#136)
* feat(windows): add an x86_64-windows cross target - packages now go through forAllTargets, adding the "x86_64-windows" pseudo-system alongside the native ones. - qt6.wrapQtAppsNoGuiHook is dropped for Windows and dontWrapQtApps set on each derivation. Both halves are needed: the hook does not evaluate for a mingw host, it would skip a PE anyway (wrap-qt-apps-hook.sh only handles ELF and Mach-O), and qtbase's setup hook hard-errors in qtPreHook without the flag. - cmakeFlags pick up pkgs.logosQtCrossCmakeFlags, which is empty natively. - meta.platforms widened to include windows. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(windows): fail loudly when the generator binary is missing The install test named only the unsuffixed `logos-cpp-generator` and had no else-branch, so a mingw build — which produces `logos-cpp-generator.exe` — copied nothing, succeeded, and shipped an EMPTY $out/bin. The failure then surfaced in whichever consumer tried to run the generator, nowhere near the cause. Probe both names, and exit 1 with a directory listing if neither is there. Verified: the Windows build now installs a real PE, and the native build is unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * chore(deps): re-pin logos-nix, logos-protocol and logos-lidl to their merged revs L1 (logos-nix) and L2 (logos-protocol, logos-lidl) are on their default branches now, so the lock can name the merged revs instead of the pre-merge branch tips it was resolving against while those PRs were open. Co-authored-by: Cursor <cursoragent@cursor.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: Cursor <cursoragent@cursor.com> |
||
|
Dario LipicarandClaude Opus 5
|
9d508292eb |
fix(generator): defer generated event subscriptions instead of acquiring a replica (#134)
* fix(generator): defer generated event subscriptions instead of acquiring a replica
Both C++ generators emitted, at all three subscription sites (the generic
on(QString, RawEventCallback), its EventCallback overload, and every typed
on<Event>):
LogosObject* origin = ensureReplica(); // blocking requestObject
if (!origin) return false; // PERMANENT -- never retried
m_client->onEvent(origin, eventName, callback);
That asks "is the module reachable right now" at the one moment the answer is
no. Every C++ consumer subscribes from init(), onContextReady() or a backend
constructor, all of which run while the dependency's host has been spawned but
has not called listen() yet. The guard inside requestObject was dead code for
years -- isConnected() returned a latch that was always true -- so the call fell
through to a blocking wait that usually succeeded, slowly. Making isConnected()
truthful turns the same code into an instant, permanent, silent failure: the
wrapper compiles, returns a bool, and never delivers.
All three sites now route through the deferred channel:
return m_client->onEventWhenAvailable(m_moduleName, eventName, callback) != 0;
and ensureReplica() / m_eventReplica are deleted from both generators. Keeping a
per-wrapper replica would reintroduce both halves at once -- a blocking acquire
on the subscriber's thread, and a permanent failure when the module had simply
not started yet.
The return becomes ACCEPTED rather than live, false only for errors no retry can
fix. That is stated in the emitted comment so it reaches every generated file
rather than only this message.
VERIFIED AT THREE LEVELS, because the first two prove less than they look:
emits -- 265/265 cpp-sdk tests. The goldens now pin the emitted CALL SITE and
EXPECT_FALSE the removed symbols; they are string comparisons and
would pass on code that does not compile, which is exactly how this
defect survived.
compiles-- both generators' output compiled against the local protocol branch
(EXIT=0), including a 15-event contract with a 3-parameter event.
defers -- real A/B on a live qt_remote transport with real generated code:
7/7 green on the migrated generator, 3/3 red in 0-8 ms on the
pristine one, with published-first controls green in both.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* chore(deps): bump logos-protocol to 0183e8c for onEventWhenAvailable
The generator change in this PR emits `m_client->onEventWhenAvailable(...)` at
all three subscription sites. This repo pinned logos-protocol 0f26ffd, which has
zero occurrences of that symbol -- compiling the emitted wrapper against it gave
EXIT=1 and 16 errors, every one "no member named 'onEventWhenAvailable' in
'LogosAPIClient'". That is why this PR was opened as a draft and why the bump has
to ride in the SAME commit range as the emission change: split them and cpp-sdk
master is red for every Qt-api-style consumer.
0183e8c is logos-protocol master with #47, #53 and #55 in. It is deliberately not
the first commit that introduces onEventWhenAvailable: #47's tip also carries the
use-after-free fix for tryAcquireNow (09f684f), without which a consumer that
subscribes more than once to a not-yet-reachable module frees a QtRO facade that
is still registered in a shared replica implementation's connect list. Generated
Qt consumers subscribe exactly that way -- one on<Event> per declared event, from
init() -- so pinning below that commit would make this change crash rather than
merely fail to compile.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Dario LipicarandClaude Opus 5
|
f8e879de36 |
test(doctests): cover the Qt-typed dependency wrapper, which nothing did (#135)
The generator emits `<dep>_api.{h,cpp}` in two type surfaces -- Qt-typed
(QString, the default) and lp (std types, Qt-free) -- and they are separately
generated bodies of code. All 7 module definitions across the 5 existing specs
declare `"interface": "universal"`, which resolves to ApiStyle::Lp. No job in
this repository compiled or executed a single line of the Qt emission, and the
consumers that actually use it are real ones: wallet-ui's backend and the
tutorial's C++ UI backend.
The new spec builds an `interface: universal` notifier and a Qt provider-style
watcher (no `interface` key -> LOGOS_API_STYLE defaults to qt), loads both in a
logoscore daemon, fires the notifier and asks the watcher what arrived.
The watcher subscribes from onInit(), not from a method the spec calls later.
That is deliberate: onInit() runs while the dependency's host process has been
spawned and has not yet called listen(), which is both the shape every real C++
consumer has and the case a reachability probe answers "no" to. Asserting
`subscriptionAccepted` AND `lastGreeted` separates "refused at subscribe time"
from "subscribed, module is just quiet" -- the two failures look identical from
the callback alone.
A zero-count control runs before the emit so the delivered count means
something, and the count is re-read after, because a subscription that re-armed
and fired twice is as wrong as one that never fired.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Dario LipicarandClaude Opus 5
|
dfd46282a7 |
chore: pin logos-protocol 0f26ffd, and move CI to Nix 2.35.1 (#133)
Bumps this repo's own `logos-protocol` root pin from 3a31c91d (Jul 31) to 0f26ffd (Aug 6, current master). Span is two protocol PRs, #40 and #41. Why per-repo pins rather than `follows` overrides: on macOS, two different protocol revisions statically linked into one process get their weak definitions coalesced by dyld, so one image's protocol code silently binds to the other's. That is not a build error — it is a runtime miscompile, and it bites across real ABI changes (`awaitCompletion` gained parameters; `RpcValue`'s variant gained `uint64_t` in the middle, renumbering later alternatives). The durable fix is for every repo in the chain to pin the same protocol, so no override is needed anywhere. CI: cachix/install-nix-action v27 -> v31, i.e. Nix 2.22.1 -> 2.35.1. 2.22.1 is old enough to mis-evaluate flake input overrides newer Nix handles fine. Nothing in this commit needs 2.35.1 — verified to evaluate on 2.22.1 too — but the rest of the chain does, and logos-standalone-app already runs v31 for exactly this reason. Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Dario LipicarandClaude Opus 5
|
f3369faca4 |
feat(generator): async callers can see the error, sync callers can set a deadline (#132)
The two consumer surfaces had complementary holes:
sync : T foo(params…, logos::CallError* err = nullptr) error yes, timeout NO
async: void fooAsync(params…, cb, Timeout = Timeout()) timeout yes, error NO
so an async caller could not tell a failed remote call from a provider that
legitimately returned 0 / "" / false — the exact ambiguity the sync path's
CallError* was added to resolve — and a sync caller could not say how long it
was willing to wait, even though the transport overload the generator already
calls takes both.
Both fixes are additive:
T foo(params…, logos::CallError* err = nullptr, Timeout timeout = Timeout());
void fooAsync(params…, std::function<void(T)> cb, Timeout timeout = Timeout()); // unchanged
void fooAsyncResult(params…, std::function<void(logos::AsyncResult<T>)> cb,
Timeout timeout = Timeout()); // new
logos::AsyncResult<T> (new, Qt-free, cpp/logos_async_result.h) is {value, error}
plus ok(); AsyncResult<void> carries only the error so every fooAsyncResult has
the same callback shape. The name is distinct rather than an overload because
std::function<void(AsyncResult<T>)> next to std::function<void(T)> is ambiguous
for a generic lambda.
Applied to both emitters that produce this surface — legacy/generator_lib.cpp
(the module-builder path) and experimental/lidl_gen_client.cpp (`--lidl
--module-only`, from a published contract) — since a consumer can reach either
for the same contract.
The Qt-free (ApiStyle::Lp) surface gets the sync timeout (spelled `int
timeout_ms`; `Timeout` lives behind a Qt header) but NOT fooAsyncResult:
logos-protocol's lp_invoke_async hard-codes `cb(1, …)`, so an AsyncResult there
would report ok() on a failed call. Measured, not assumed. See the note in
makeHeaderLp.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Dario Lipicar
|
d972fe207a |
fix(generator): no silent drops — unread STRUCTURE in a record is a build error (#131)
#127 made an unknown C++ TYPE a build error instead of a silent `any`. This is the same hole one level down, in the record scanner: a line inside a `struct` body that the scanner could not read as a field was `continue`d, and the struct was published anyway — MINUS that field. A field list is not a detail of a record, it IS the record: the promise every other language binds to. A contract with two fields is exactly as well-formed as one with three, so nothing downstream could tell. Measured on the generator built from master: struct SplitRecord { -> type SplitRecord { exit 0, no diagnostic std::string id; id: tstr std::vector<std::string> n: uint tags; } uint64_t n; }; `tags` is simply GONE struct Outer { -> type Outer { a: int } exit 0 struct Inner { the record is made of the INNER type's int64_t a; field and has none of its own }; Inner inner; std::string label; }; struct Pair { -> method echoPair(v: Pair) with NO `type Pair` std::string first; std::string second; emitted — a contract naming a }; type it never declares struct Defaulted { -> the brace-initialised field is dropped std::string id{"none"}; (only the `= v` form was recognised) int64_t n = 0; }; struct Allman -> not a record AT ALL, so every mention of it { falls to the `any` fallback — since #127 an std::string id; error whose hint says "declare a struct", }; which is the thing the author declared The scanner now reads a body as DECLARATIONS rather than lines. Physical lines are joined until the declaration is whole — a `;` at the struct's own brace depth, or a `}` there, which is how a member function defined inline ends — exactly as the caller already joins a method signature until its parentheses balance. Where a brace sits, and where a line wraps, cannot decide what a header means. Allman and base-clause openings are recognised for the same reason. Whatever is left after that, and after the constructs that definitively are NOT fields (member functions, `using`/`typedef`/`friend`/`static`, access specifiers), is reported instead of skipped, naming the struct, the declaration and the fix. Same withdrawal discipline as #127: the diagnostic is keyed on the struct and tested against the API-REFERENCED set, so a helper struct the module never publishes may be as unreadable as it likes — every real module carries one (openmetrics' `ModuleSource`, the package manager's `PendingAction`). Comments come off with a literal-aware strip. The old bare `indexOf("//")` truncated `std::string url = "http://x";` inside the literal, which merely lost the field before and would now reject valid code. Blast radius, measured: all 27 universal-interface impl headers in the workspace emit BYTE-IDENTICAL .lidl and stderr, with identical exit codes. All 6 structs those headers declare are K&R with no unparsed body line, so nothing in tree changes. logos-qt-generator, which compiles this same file, builds; and test_fullapi_ext_cpp — the records-heavy module — builds end to end. 14 new tests. 10 of them fail on the unpatched parser; the rest are the "must still work" controls, including one for an inline member-function body that an earlier cut of this change would have broken. |
||
|
Dario LipicarandClaude Opus 5
|
b4c2e5bb2d |
fix(generator): one declaration, one binding — optional record fields on the legacy path (#130)
`? maybe: tstr` and `maybe: ?tstr` are the same declaration. logos-lidl's
docs/spec.md says so and requires them to produce byte-identical code, and
logos-lidl#7 added fieldIsOptional()/fieldValueType() precisely so no backend
re-derives the answer. The cdylib, client-stub and both Rust backends honour
that. The LEGACY consumer path — the one every real C++ module builds through,
`logos-cpp-generator --general-only --dep <name>=<lidl>` from
logos-plugin-qt's buildPlugin.nix — did not:
? maybe: tstr -> QString maybe{}; __m.value("maybe").toString()
maybe: ?tstr -> QVariant maybe{}; __m.value("maybe")
and on `--api-style lp`, `std::string maybe{}` vs `LogosMap maybe{}` — neither
of them std::optional. The flag spelling is the one production contracts use:
logos-chat-module writes all five of its optionals that way, so every one of
them landed on the branch that silently defaults. A `QString` has no empty
inhabitant at all; an absent `nickname` and an empty-string one were the same
value by the time the consumer saw them.
ROOT CAUSE. legacy/main.cpp's moduleRecordsToJson / moduleMethodsToJson /
moduleEventsToJson flatten every TypeExpr into a single Qt TYPE-NAME STRING.
Answering "is this optional" from a name means answering it from the verbatim
spelling, which is the one thing the accessors exist to stop.
WHAT THIS CHANGES. The record-field half of that boundary, and only it. A field
object now carries `optional` alongside `type`, where `type` is the VALUE type
(fieldValueType) and `optional` is true for either spelling (fieldIsOptional).
Both spellings arrive at the emitter as the same object, so they leave as the
same code. Per surface, matching the sibling backend that already serves it:
Qt — QVariant, as lidl_gen_client.cpp already emits. Qt has no optional
template; an invalid QVariant is its single empty inhabitant. Two-state,
untyped.
Lp — std::optional<T>, as lidl_gen_cdylib.cpp already emits, encoded by
logos-protocol's Codec<std::optional<T>>. Keeps the value type.
`?any` / `?{K:V}` / `?[any]` collapse onto the bare LogosMap/LogosList:
nlohmann::json already carries null, so wrapping it would give the slot
two empty spellings — three states, which the two-state rule forbids.
Encode omits the key when empty (a record field is a NAMED slot); decode treats
an absent key and an explicit null as the same state, so neither turns empty
into "" or 0. The round trip is canonicalising, as the spec requires.
The three functions move to legacy/lidl_to_json.{h,cpp}. Not cosmetic: the rule
is a property of frontend -> JSON -> emitter, and while they sat inside a TU
with main() no test could observe it. tests/generator/test_optional_spellings.cpp
now runs that composition end to end.
WHAT THIS DOES NOT CHANGE, and why. POSITIONAL slots — method parameters,
return types, event parameters — are still flattened to QVariant (Qt) /
LogosMap (Lp). They have no name to hang a flag on, so they only ever had the
type-kind spelling and there is no divergence there to fix; what they lose is
the value type. Closing that changes generated method SIGNATURES, i.e. a source
break for every existing call site, for a defect this commit is not about.
`OptionalSpellings.PositionalSlotsAreStillFlattened` pins the current behaviour
so closing it later is deliberate, and the generator still prints a `Note:`
naming every slot it flattens. Nesting, map key types and descriptions still do
not cross the boundary either — the flag is per-field, not a general widening.
VERIFIED BY RUNNING, each check shown to fail when the property does not hold:
- Two contracts identical but for the spelling, generated with `--dep` on both
`--api-style qt` and `--api-style lp`: byte-identical. The SAME comparison on
a generator built from this base without the fix reports a difference on
both styles.
- Harness sensitivity: two contracts differing only in `count: uint` ->
`count: int` are reported as different, so the compare is not vacuous.
- A contract with no optional field generates byte-identically to the
unpatched generator, both styles — and the same compare reports a difference
when given genuinely different output.
- The 5 new assertions FAIL on this base with only the extraction grafted in
(generator_lib.cpp pristine) and pass with the fix; the 3 control assertions
pass on both, which is what makes them controls.
- Generated wrappers compile on both surfaces, for the probe contracts and for
the real logos-chat-module and test_fullapi_ext_rust contracts.
- Emitted lp record codec exercised at runtime: empty omits the key, an
explicit null decodes to nullopt rather than "", uint64 above 2^63 survives,
bstr stays canonically tagged, and `{"maybe": null}` re-encodes omitted.
- `nix build .#tests` green (107 tests), `nix build .#cpp-generator` green.
logos-qt-sdk's qt-generator has the same defect in lidl_gen_qt_consumer.cpp
(record fields read `f.type` directly); it is a separate repo and not touched
here.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Dario Lipicar
|
b594d1a38c |
fix(generator): the Qt consumer must not flatten a rejection into an empty value (#129)
* fix(generator): the Qt consumer must not flatten a rejection into an empty value
A provider that REJECTS a call answers the canonical
{"code":"dispatch_failed", "message":..., "origin":...} object as its RESULT,
not as a transport error — the same object from every provider flavour
(logos-qt-sdk dispatchFailedVariant, the generated cdylib dispatch, the Rust
provider's args::dispatch_failed).
The generated Qt consumer wrapper converted it like any other value, which
ERASES it. `_result.toList()` on that map is `[]`, `.toString()` is "",
`.toLongLong()` is 0 — so `echoUintList([1, -1, 3])`, answered `dispatch_failed`
by the provider, reached the caller as `[]`: the whole list, not the bad
element, and indistinguishable from "the provider returned nothing". Losing the
error is a consumer bug whatever the provider did.
Reported through the channel this surface already uses for a failed call: the
`logos::CallError*` out-parameter every generated sync method carries (today
"object_unavailable" when the target cannot be acquired). No signature changes,
no return value changes — a caller that passes `err` now sees
code="dispatch_failed" with the provider's diagnostic and origin; a caller that
does not gets the same default it always got, plus the qWarning the wrapper
already emits for a failed call.
* the detector is emitted once per wrapper, in an anonymous namespace, and
matches EXACTLY (three string fields, that code) for the same reason
logos_rpc_status.h's isUnauthorizedSentinel matches exactly: an `any` or map
return carrying user data must never false-match.
* the result is now captured for `void` returns too — a void method can be
rejected, and the rejection object is the only place that says so.
* the async overload's callback takes the value alone and has no error
parameter; giving it one would change the generated public surface (which
logos-qt-sdk's veneer mirrors 1:1), so an async rejection is logged rather
than delivered. Recorded in cpp-generator/docs/project.md.
Scope: CONSUMER side only. The provider half of registry entry Q1 (a Qt-typed
provider cannot validate the ELEMENT of a typed numeric array, because a C++
signature spells [uint] and [any] alike as QVariantList) is explicitly out of
scope and unchanged. The lp wrapper is untouched — its generated output is
byte-identical before and after.
* fix(generator): guard the emitted detector — the umbrella is one translation unit
`logos_sdk.cpp` textually `#include`s every generated `<dep>_api.cpp`, so a
module with more than one dependency compiles several copies of the detector
into ONE translation unit:
test_fullapi_rust_api.cpp:15:6: error: redefinition of 'logosDispatchRejection'
Internal linkage covers the separate-TU case; only the preprocessor covers this
one. Found by building test_fullapi_qtproxy (3 wrappers: two concrete deps plus
the bound `full_api` interface) against this generator — a single-wrapper
contract cannot reach it.
|
||
|
Dario LipicarandClaude Opus 5
|
8c3d7d4253 |
chore(deps): bump logos-protocol to 3a31c91d (off-strand socket close races) (#128)
Picks up logos-protocol #38 and #39, two off-strand socket-close races in the plain (tcp / tcp_ssl) transports: #38 RpcConnection::fail() closed the socket on the caller's thread while every other stream access was serialized on m_strand, racing kqueue_reactor::start_op and segfaulting the client on teardown. #39 The same class of bug on RpcServer's acceptor. Both are FALSE NEGATIVES rather than lost work: the RPC completes and prints its correct result, then teardown crashes, so a caller that checks the exit code before parsing stdout reports a healthy call as failed. Measured at ~0.45% of calls over tcp/tcp_ssl, zero over local/QtRO. logos-cpp-sdk ships no protocol runtime code of its own -- the generator only #includes protocol headers (logos_provider_interface.h, logos_json_convert.h) and the header-only SDK does not link it at all. So this is a propagation bump: it is cpp-sdk's pin that downstream repos inherit through `follows`. Verification: * The lock has exactly one logos-protocol node and it is on 3a31c91d; no other node in the closure carries a protocol input. * The real (unwrapped) generator binary is BYTE-IDENTICAL across the bump -- sha256 1ceb6b9d2517d58f...; only the Nix wrapper differs, and only in its own embedded store path. Explained by the upstream diff, which touches solely cpp/implementations/plain/rpc_{connection,server}.* plus protocol's own tests. * Emitted-code equivalence over the workspace corpus, base vs bumped generator: 142 invocation pairs / 469 emitted files, zero differences, across --general-only (--interface and --dep, both --api-style qt and lp), --lidl, --lidl --backend cdylib --impl-class, --from-header --backend cdylib, and --header-to-lidl. Harness sensitivity proved by a qt-vs-lp negative control (42/42 differ) and by input mutation (39/39 successful runs change). * Unit tests: 218/218 pass, identical to origin/master (218/218). Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Dario LipicarandClaude Opus 5
|
44b92b0480 |
feat(generator): no silent admissions — an unknown C++ spelling is a build error (salvage of #112) (#127)
* feat(parser): name nlohmann::json explicitly, ahead of killing the fallback `nlohmann::json` (and the `json` alias) has never had a branch in cppTypeToLidl. It reaches the opaque `any` the same way every unrecognised spelling does: the fallback at the bottom of the function. That is fine while the fallback is silent and wrong the moment it becomes an error, because `any` is the RIGHT answer here. test_fullapi_cpp declares `nlohmann::json echoAny(const nlohmann::json&)`, `bool fireAnyEvent(const nlohmann::json&)` and `logos_events: void anyEvent(const nlohmann::json&)`, and those three are the cross-language conformance chain's `any` cells — they must keep publishing `any`. So this lands first and on its own. It maps to the bare `any` primitive, which is exactly what the fallback already produced, making the change output-neutral: generating over every impl header and every .lidl in the workspace produces 764 byte-identical artifacts. That is what lets the later commit treat everything still reaching the fallback as a silent admission rather than a legitimate `any`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * feat(cdylib): a typed map decodes into the author's own container `{tstr: T}` has two C++ spellings — std::map<std::string, T> and std::unordered_map<std::string, T> — and logos_codec.h specializes Codec for both, because they are the same wire shape. The generated dispatch named one: lidlImpl().echoIntMap(logos::fromJson<std::map<std::string, int64_t>>(...)) fromJson returns a std::map, and a std::map does not convert to an unordered_map parameter. So the container the author picked decided whether generated code they never wrote compiles — with the diagnostic pointing at that generated line, not at their declaration. logos::JsonArg (logos-protocol, already on master) exists for exactly this: it instantiates its conversion operator with the parameter's own type, so the author's declaration drives the decode. The return side is the same problem mirrored, and `logos::toJson(result)` deduces instead of asserting. Restricted to Map because every other LIDL type has one C++ spelling here, and because JsonArg documents one target it cannot serve — std::optional<X>, whose converting constructor out-ranks the proxy's conversion operator. The Optional branch returns before reaching this code. For a std::map author nothing changes: JsonArg instantiates the same Codec<std::map<...>>::from at the same path, and toJson deduces the same T. Compile-checked against both spellings, including a bad element still failing with `expected string at arg0.k, got number`. Across the whole workspace the emitted delta is 5 methods, all in test_fullapi_ext. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * feat(parser): an unknown C++ spelling is a build error, not a silent `any` cppTypeToLidl ended with `// Fallback: treat as opaque` -> `any`, and `any` is ADMITTED by every backend gate. So a spelling nobody had written a branch for was accepted in silence, published as `any`, and dispatched as a bare `lidlImpl().f(args.at(0))` — no logos::fromJson<>, no check. That is the one hole #113-#122 closed for every typed slot and left open for anything that reached `any`. An 11-method hostile probe was admitted wholesale: uint32_t, size_t, float and uint8_t all typed as `any`; std::set, std::vector<std::pair<...>> and a non-string-keyed map as `any`; std::vector<uint32_t> as `[any]`. Now every spelling with no LIDL type is collected with the declaration that carries it, and parseImplHeader turns the list into a parse error naming the offending type and the fix: method 'send_generic_public_transaction': parameter 'instruction' declared `const std::vector<uint32_t>&`, whose element `uint32_t` has no LIDL type. LIDL numbers are 64-bit only. Declare it `uint64_t` (LIDL `uint`). Widening is source-compatible for every caller; a narrow type on the wire is not, which is why LIDL has none. Numbers get that tailored hint (uint8_t its own — it means bytes here, and only as std::vector<uint8_t>); sets, pairs/tuples, non-string map keys, list/deque/array, Qt types and pointers each get theirs; anything else gets the full table of recognised spellings. A hint that does not name a replacement just moves the guesswork, so all of them do. std::unordered_map<std::string, T> joins std::map as a spelling of `{tstr: T}` — the codec has always handled both, and the previous commit made the generated dispatch bind whichever the author declared. Two slots are the exception and say so: a record FIELD and an event PARAMETER, where the generator writes the spelling out into code the author's own declaration has to match and can only pick one name. Three properties keep this from breaking things it should not: * The MAPPING is unchanged. cppTypeToLidl still returns `any` for an unsupported spelling; only a diagnostic is recorded. A diagnostic that is later withdrawn therefore leaves output byte-identical. * Diagnostics are withdrawn for declarations that never reach the contract — a helper struct dropped by keepOnlyReferencedRecords, a reserved lifecycle hook (onContextReady and friends), a struct with no parsed fields. Publishing is what makes a type a promise. * An empty spelling is not a C++ type, it is this line-based parser failing to find one. It keeps the old behaviour rather than reporting `''`. Also fixes a latent ordering bug found while threading the context through: metadata.json's event parameters were typed BEFORE the header was read, i.e. against whatever g_recordNames the previous module's parse had left behind. They are now read there and typed after scanForRecords, in the same position in module.events as before. Verified by generating over every impl header and every .lidl in the workspace: 31 derived contracts byte-identical, 368 consumer-umbrella files byte-identical under both --api-style qt and --api-style lp, 46 generated types headers byte-identical. Exactly two modules now fail, at exactly the four slots a prior scan identified as silent admissions. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * feat(cdylib): a wrong argument count reports invalid_args The arity gate was `if (args.size() < N) return nullptr;`. The Qt glue turns a NULL reply into an empty QVariant, so "you passed 2 of 4 arguments" was indistinguishable from a method that legitimately returned nothing. logos-rust-sdk already ships the other half. src/args.rs::invalid_args is documented "Same code and message as the C++ generated glue" and pinned by a test named invalid_args_shape_matches_cpp — both of which were false: Rust answered a structured object and C++ answered NULL. Checked against the JSON that crate actually emits rather than against its comment, the two are now byte-identical: {"code":"invalid_args","message":"expected 4 arguments, got 2","origin":"my_module"} `expected` counts REQUIRED parameters in both, so a trailing optional does not change it. The guard is emitted only when the method has at least one required parameter. args.size() is unsigned, so `< 0` never fires: a zero-argument method carried a dead branch. The Rust generator skips it for the same reason, so the two now agree on when a check exists at all. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * refactor(cdylib): delete the dead emitted base64 codec #117 replaced the codec the generator emitted into every module with logos-protocol's logos_codec.h, but left the base64 pair it had grown around: * lidlB64Idx + lidlBytesFromJson — 55 emitted lines with NO call site at all. Every byte parameter had already moved to logos::bytesFromJsonLenient. Confirmed across the whole workspace: in 48 generated export TUs, all 48 mentions of lidlBytesFromJson are its own definition line. * lidlB64UrlEncode + lidlBytesToJson — 34 emitted lines that are logos::bytesToJson rewritten, in a translation unit that already includes it through "<module>_types.h". Scalar bstr slots now call logos::bytesToJson. Composite ones ([bstr], {tstr: bstr}, records) have gone through logos::Codec since #117, so this removes the last place a module carried its own copy of an encoder — the arrangement that once let the emitted and canonical halves disagree about padded base64, and that #117's own comment set out to end. hasBytesEventParam goes with it: it existed only to keep the emitted copy from sitting unused in the events sidecar of modules whose events carry no binary data, and the `namespace { }` block it gated is gone too. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(doctest): the bstr event marshal is logos::bytesToJson now Commit (D) deleted the dead emitted base64 codec, so the cdylib events sidecar calls logos::bytesToJson -- the one in logos_codec.h, included in the same translation unit -- instead of emitting its own lidlBytesToJson. The doctest still pinned the old spelling and failed on the new output: expected 'args.push_back(lidlBytesToJson(frame));' not found in output The prose around it is unchanged and still correct: the payload is still the canonical {"_bytes": "<base64url>"} form, which is the property that assertion exists to guard (#99). Only the symbol moved. Verified against real generator output rather than by search-and-replace: built the branch generator, ran --backend cdylib over a sensor_module contract with a bstr event param, and read the emitted line: args.push_back(logos::bytesToJson(frame)); Checked the rest of the specs for other stale symbols (lidlStrdup, b64Url, hasBytesEventParam, the old 'return nullptr' arity gate) -- this was the only one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Dario LipicarandClaude Opus 5
|
5a809c17a6 |
docs(generator): record where a dependency entry is read (#126)
The generator's own description still had `dependencies[]` as a list of names, and the shared-helper list under share/lidl-frontend still had the three files it had before metadata_dependencies.h joined them — the one a reader consults before adding a header that impl_header_parser.cpp includes, which is how the qt-generator's build breaks from a change made here. Documents both entry forms where the umbrella is described, and why the array is read once rather than per emitter: the aggregate is emitted by several passes, and passes that answer that question separately can answer it differently, which is a member whose type was never included. Also notes the umbrella emitters' new home in generator_lib, the tests that cover them, and the fixture declaring both forms. Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Dario LipicarandClaude Opus 5
|
198f0317ca |
feat(optional): ?T is two-state, and the generators finally read it (#125)
* feat(optional): ?T is two-state, and the generators finally read it
No generator in any language read the optional flag — it had never been
implemented. `?T` was a HARD REJECT on the cdylib backend ("module not
cdylib-eligible"), `std::optional<T>` in an impl header fell through to the
opaque `any` with no diagnostic, and a `? name: T` field was emitted as a
required `T`. Three real contracts in the workspace already declare optionals
and were silently getting one of those three answers.
`?T` is TWO-state: a value of T, or empty. Never three — "one LIDL type <-> one
type per language" leaves nowhere for a third state, because every target has
exactly one empty inhabitant.
ONE MEANING, TWO SPELLINGS. `? name: T` (the field flag) and `name: ?T` (the
type kind) are the same declaration. Backends no longer answer that themselves:
logos-lidl's fieldIsOptional/fieldValueType are re-exported from lidl_compat.h
and every site THIS COMMIT TOUCHES reads them, so the two spellings emit
byte-identical code on the cdylib and client backends. That
caught a live drift on the way in — lidlRecordCollidesWithBytesTag read `f.type`
and so refused `? _bytes: tstr` while letting `_bytes: ?tstr` straight through,
one declaration with two answers.
THE WIRE RULE DEPENDS ON THE SLOT. Absent and explicit null are the SAME state
on decode and DIFFERENT on encode:
- decode is liberal, by exactly one inhabitant: in an optional slot absent and
null both mean empty; in a required slot both stay errors. A present value
goes through the decoder a required T would get, so a wrong type still fails
at the same path — optional widens the domain, it does not switch checking
off. `?bstr` therefore keeps the LENIENT bytes decode a bare `bstr` gets,
rather than silently becoming stricter in the optional slot.
- encode has one canonical form: empty OMITS the key where the slot is NAMED
(a record field) and is spelled null where it is POSITIONAL (an argument, a
return, an event parameter — no key to omit, and arity must not change). Key
omission lives in the record emitter because a Codec only ever sees a value,
never the slot it sits in. A round trip therefore canonicalises.
- `?any` collapses onto `any`: nlohmann::json already carries null, so
std::optional<LogosMap> would give the slot two spellings of empty.
The dispatch gate now admits a missing trailing optional argument and
materialises it as null, exactly the way a missing record field already was. A
method with no optional parameter emits the byte-identical gate it always did.
Header-first: `std::optional<T>` <-> `?T`, composing with records and
containers. `std::optional<std::optional<T>>` has NO LIDL type (three C++ states
over a two-state wire), so it maps down to `?T` — which makes the author's own
declaration stop compiling against the generated codec, deliberately — and says
so at derivation time instead of leaving a conversion error in generated code.
The Qt/Lp consumer surface is NOT fixed and does not pretend to be. The wrappers
real modules get come from legacy/main.cpp, where the AST is flattened to a
single Qt type-name string per slot before optionality could be seen; Qt has no
optional metatype, so `?T` lands on QVariant — the right shape (an invalid
QVariant is Qt's empty inhabitant) with no type. The generator now prints a Note
naming every flattened slot so an affected build is never silent, and
docs/project.md records exactly what a Qt consumer will still do with an
optional field.
Verified by output equivalence, not by a green build: the generator was built
before and after and run over every .lidl in the workspace plus the impl-header
fixtures, in cdylib, consumer-qt, consumer-lp, client and header-first modes.
428 of 465 artefacts are byte-identical; all 37 that differ belong to one of the
four contracts that declare an optional (the 38th path is the manifest). The
harness's sensitivity is pinned by a negative control: qt vs lp output differs
in 45 files. The emitted codec was additionally compiled under -Wall -Wextra and
run against the rules above — omission, absent==null, required-still-rejects,
present-but-wrong-still-fails, and canonicalising round trip.
Tests: 199 pass, 0 fail (180 before, 19 new).
Requires logos-lidl's optionality accessors and logos-protocol's
Codec<std::optional<T>>.
NOT FIXED, AND IT IS THE PATH THAT MATTERS MOST. The legacy interface-wrapper
path is untouched, and it is the one every real module builds through
(buildPlugin.nix:145 -> logos-cpp-generator --general-only). There the two
spellings still diverge:
? maybe: tstr -> QString maybe{}; __m.value("maybe").toString()
maybe: ?tstr -> QVariant maybe{}; __m.value("maybe")
and --api-style lp diverges too, neither side being std::optional. So R3 holds
on the backends below and NOT on the Qt consumer a shipping module actually
gets. logos-chat-module -- the contract that prompted this work -- uses the
field-flag spelling, so it lands on the branch that silently defaults.
The cause is upstream of codegen: legacy/main.cpp's moduleRecordsToJson and
moduleMethodsToJson flatten every TypeExpr to a single Qt TYPE-NAME STRING, so
optionality (along with nesting, map key types and descriptions) is gone before
generator_lib.cpp sees it. Widening that interface is a larger change and is
deliberately not attempted here. The only R3 test on a Qt surface covers
lidl_gen_client.cpp, which is on no live build path.
* chore: re-pin logos-lidl to master for the optionality accessors
lidl_compat.h re-exports typeIsOptional / optionalValueType / fieldIsOptional /
fieldValueType / paramIsOptional / paramValueType, which landed in
logos-lidl#7. The pinned lidl predated it, so CI failed to compile.
logos-lidl 8c95d4f -> 35f33d8. Tests: 199 pass, 0 fail.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* chore: re-pin logos-protocol to master for Codec<std::optional<T>>
The generated record codecs emit Codec<std::optional<T>> for an optional
field; that specialisation landed in logos-protocol#37 and the pinned
protocol predated it.
Note this repo's own tests would NOT have caught the omission -- the
generator tests string-assert emitted text rather than compiling it, so a
missing codec specialisation only surfaces when a real module compiles
generated optional code (logos-test-modules' ext provider).
logos-protocol 4359557 -> 72754ab. Tests: 199 pass, 0 fail.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* test(doctests): override logos-lidl alongside every logos-cpp-sdk override
The doc-tests build downstream repos (logoscore-cli, capability_module,
accounts_module) with --override-input logos-cpp-sdk. Nix does not carry the
overridden input's OWN lock, so those builds got this branch's cpp-sdk source
while still resolving logos-lidl from their own, older locks. The shipped
share/lidl-frontend/lidl_compat.h then calls accessors that lidl does not
have:
lidl_compat.h:46: error: 'paramValueType' has not been declared in 'lidl'
lidl_compat.h:92: error: 'fieldValueType' was not declared in this scope
Every --override-input logos-cpp-sdk now has a matching
--override-input <same-path>/logos-cpp-sdk/logos-lidl.
This is specific to the override path. A normal consumer running
'nix flake update logos-cpp-sdk' inherits cpp-sdk's own lock, which pins the
lidl carrying these accessors, and is unaffected.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* test(doctests): move logos-lidl at the qt-sdk nodes, not under logos-cpp-sdk
The doc-tests failed to build logos-qt-generator:
share/lidl-frontend/lidl_compat.h:46: error: 'paramValueType' has not been
declared in 'lidl'
MECHANISM. This SDK installs cpp-generator/experimental/lidl_compat.h into
$out/share/lidl-frontend/, and logos-qt-sdk's logos-qt-generator *compiles*
that installed header against qt-sdk's OWN logos-lidl input. Under
logos-qt-sdk, logos-lidl is a SIBLING of logos-cpp-sdk, not a descendant:
logos-qt-sdk
|-- logos-cpp-sdk <- --override-input moves this to the commit under test
`-- logos-lidl <- stays on qt-sdk's lock (8c95d4f), lacks the accessors
logos-logoscore-cli and logos-module-builder both declare
`logos-qt-sdk.inputs.logos-cpp-sdk.follows = "logos-cpp-sdk"` but no lidl
follows, so overriding the SDK hands qt-sdk a new lidl_compat.h next to its
old lidl. The failing derivation is logos-qt-generator — not anything in
logos-cpp-sdk, which is why the previous attempt aimed at the wrong node.
THE FIX is one `<path-to-logos-qt-sdk>/logos-lidl` override per qt-sdk node
that ends up on the SDK under test. A tree-walk over the resolved lock found
four in logoscore-cli's closure and two per module build; with the overrides
applied the walk reports zero remaining.
WHAT WAS REMOVED, and why it was doing nothing:
* The `.../logos-cpp-sdk/logos-lidl` overrides added in
|
||
|
|
fde0f6fccb |
fix: read dependency entries declared in object form (#123)
* fix: read dependency entries declared in object form The manifest schema lets a dependency entry be an object carrying the name alongside the constraints an installer resolves it by, but every reader took the element as a plain string and skipped what came back empty, so an object entry disappeared: the module it names was left out of the generated LogosModules aggregate, and every call through it failed to compile. The rule lives in one place now, since the copies of it are how the gap spread. It ships in share/lidl-frontend alongside the parser that includes it, which consumers compile from there. * fix: read every dependency entry through one pass over the array The object form reached the umbrella's members and constructor but not its includes: that emitter still read each element as a plain string, so a module declared in object form came out as a member whose type was never included, and the aggregate no longer compiled. It is the Qt-free umbrella, which is what every universal core module and every cdylib module generates, so the form the previous commit set out to support failed there in a new way rather than working. Reading the array element by element is what let one pass disagree with the next, so no reader does that any more: dependencyNames() answers what an array declares, once, and the emitters walk names. That leaves the entry form knowable in exactly one place, and the includes and members of an aggregate can no longer be built from different answers. The umbrella emission moves to generator_lib alongside the per-module wrapper emitters it mirrors, returning the text instead of writing it, so what it generates can be asserted on directly; main.cpp writes what it returns. Output for string-form dependencies is byte-identical in both API styles, with and without interface dependencies. The listing mode (`--metadata` with no `--module-dir`) went the same way — it was the last reader still deciding on its own. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Dario Gabriel Lipicar <dario@status.im> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Dario LipicarandClaude Opus 5
|
d11fbb2220 |
docs: drop the reference to the deleted lidlGenerateProviderGlue (#124)
logos-qt-sdk#23 deleted that function -- it was a second, parallel top-level pipeline over the same emitters main.cpp already drives, with no callers anywhere in the workspace. This doc bullet was its only surviving reference. The .lidl sidecar the bullet described is emitted elsewhere and is unaffected: main.cpp:92/:184 here, and module-builder's modulePreConfigure.nix:75. Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Dario LipicarandClaude Opus 5
|
99a2bffeb3 |
refactor(generator): drop the dead event-source surface from consumer wrappers (#120)
* fix(generator): one Qt type mapper, and it knows about void; LpClient takes a timeout
Two near-duplicate LIDL->Qt type mappers existed — legacy/main.cpp's
lidlTypeExprToQtTypeName and experimental/lidl_emit_common.cpp's lidlTypeToQt —
and they disagreed. The legacy one had no `void` case, so a `-> void` method
arriving as Primitive("void") from the impl-header parser fell through to
QVariant. (The .lidl parser spells it Named("void"), which survived only by
accident, through mapReturnType's `base == "void"` early-out.)
That was not a Qt-consumer bug: the std/lp tables are DERIVED from this name, so
the same method generated `LogosMap doVoid(...)` on the Qt-free surface too.
Measured, from `void doVoid();` in a .h interface:
QVariant doVoid(...) --api-style qt before
void doVoid(...) --api-style qt after
LogosMap doVoid(...) --api-style lp before
void doVoid(...) --api-style lp after
lidlTypeExprToQtTypeName is now a delegation, so there is one table to disagree
with. This changes the generated signature for any module consuming a `-> void`
method through a .h interface; the two in-tree call sites discard the value and
are unaffected.
logos::LpClient::invoke/invokeAsync gain a timeout_ms parameter, defaulted to
the C ABI's "use the default" (0) so no existing caller changes. The Qt-typed
consumer surface takes a Timeout on every async overload and had nowhere to put
it — a wrapper delegating to the lp path silently dropped it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* refactor(generator): drop the dead event-source surface from consumer wrappers
Generated consumer wrappers carried setEventSource / eventSource / trigger — an
author-facing way to SOURCE events through a wrapper whose job is to CONSUME
them. Both emitters (legacy and experimental) shipped it.
Nothing used it. Zero call sites across every repo in the workspace including
the vendored SDK copies; the only `trigger(` in the tree is a QML Action's own
method. The generated code did not use it internally either — m_eventSource was
written only by its own setter and read only by trigger, so calling trigger()
without a prior setEventSource() warned and returned.
It was not free. `trigger` routes through m_client->onEventResponse, which has
no lp equivalent — lp_* offers only lp_provider_emit_event, on a handle a
consumer wrapper does not own. That single call was the reason a Qt wrapper had
to keep a LogosAPIClient alongside its lp client, carrying two clients and two
lots of token state per wrapper. Removing an unused surface removes a real
constraint on the veneer.
Worth noting what it would have taken otherwise: either widening the C ABI with
a consumer-side emit (softening a provider/consumer split the ABI currently
enforces), or rerouting through the module's own provider handle. Neither is
needed if nobody is asking.
Pinned by a test rather than left to convention — the emitters are the kind of
code where a convenience accessor grows back.
181/181.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Dario LipicarandClaude Opus 5
|
5d0a99a182 |
chore(generator): retire ApiStyle::Std (#122)
The Std surface — std-typed signatures over a QVariant + LogosAPIClient body — no longer had a caller. `interface: "universal"` modules moved to `lp` (std types over the Qt-free logos-protocol C ABI), and nothing else ever selected it, so every Std branch was dead weight sitting in front of the two live ones. `--api-style=std` is now rejected with a message naming the retirement rather than aliased to `qt`. A stale caller that still passes it wants std signatures; handing it the Qt surface would fail later, further from the cause. The collapse is deliberate about the branches where Std was tested BEFORE Qt, since a naive "delete the block containing ApiStyle::Std" changes Qt output: - makeHeader's include block tested Std first, so its `else` is the Qt include list — the Qt includes are kept and promoted, not deleted. - recordToWireExpr / recordFromWireExpr returned the Qt map form from a guarded `if` and the Std form from the function's trailing `return`. The guard is dropped and the Qt form promoted to the tail; deleting only the trailing return would have left a path falling off the end. - The private-member `else if (!events.isEmpty())` arm reads as an event test but was Std-only; the Qt arm (m_eventReplica + m_eventSource) survives, so setEventSource/trigger still have their storage. - `if (apiStyle == Qt || !events.isEmpty())` is a disjunction, not an Std branch: it unwraps to an unconditional emit, keeping ensureReplica()'s declaration next to its definition. - `isRec || style == Std` loses only the right disjunct — dropping `isRec ||` would double-wrap record fields in QVariant::fromValue. mapParamTypeStd / mapReturnTypeStd / isStdRefType stay: they are the shared std type table that ApiStyle::Lp reaches through the non-Qt arm of paramTypeFor / returnTypeFor / byRefFor and directly from lpPushExpr / lpFromJsonExpr. Verified by output equivalence rather than by the build succeeding: the generator was run over 13 fixture cases (the full_api contract as both a bound interface and a baked dep, three record-bearing contracts incl. map-of-record fields, the chat module's production contract, and a no-events contract) for both qt and lp, before and after. `diff -r` over the 194 resulting files reports no differences, and the experimental --lidl backends are byte-identical too. Test suite: 180/180, unchanged. Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Dario LipicarandClaude Opus 5
|
8e7ed6e0ec |
fix(generator): the provider dispatch decodes arguments, it does not coerce (#121)
The --provider-header dispatch emitted args.at(0).toULongLong() and friends, so echoUint(-1) reached the author's method as 18446744073709551615 and echoInt(3.7) as 4. It now emits logos::qtArgFromVariant<T> per parameter — the same canonical codec the cdylib dispatch and the Rust provider use — and turns a logos::CodecError into the canonical dispatch_failed object. toQVariantConversion is untouched: it is also used for the Qt CONSUMER wrapper's return conversion, which is a different direction. The new toProviderArgDecode covers only the incoming-argument job, and falls back to the old conversion for a type the codec has no rule for so a module author's own type still compiles. Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Dario LipicarandClaude Opus 5
|
9a6d7b8228 |
fix(generator): one Qt type mapper, and it knows about void; LpClient takes a timeout (#119)
Two near-duplicate LIDL->Qt type mappers existed — legacy/main.cpp's
lidlTypeExprToQtTypeName and experimental/lidl_emit_common.cpp's lidlTypeToQt —
and they disagreed. The legacy one had no `void` case, so a `-> void` method
arriving as Primitive("void") from the impl-header parser fell through to
QVariant. (The .lidl parser spells it Named("void"), which survived only by
accident, through mapReturnType's `base == "void"` early-out.)
That was not a Qt-consumer bug: the std/lp tables are DERIVED from this name, so
the same method generated `LogosMap doVoid(...)` on the Qt-free surface too.
Measured, from `void doVoid();` in a .h interface:
QVariant doVoid(...) --api-style qt before
void doVoid(...) --api-style qt after
LogosMap doVoid(...) --api-style lp before
void doVoid(...) --api-style lp after
lidlTypeExprToQtTypeName is now a delegation, so there is one table to disagree
with. This changes the generated signature for any module consuming a `-> void`
method through a .h interface; the two in-tree call sites discard the value and
are unaffected.
logos::LpClient::invoke/invokeAsync gain a timeout_ms parameter, defaulted to
the C ABI's "use the default" (0) so no existing caller changes. The Qt-typed
consumer surface takes a Timeout on every async overload and had nowhere to put
it — a wrapper delegating to the lp path silently dropped it.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Dario LipicarandClaude Opus 5
|
5f63af681a |
fix(tests): stop reaching across repos for the canonical byte helpers (#118)
#117 left tests/sdk/test_logos_json_bytes.cpp including logos_codec.h and logos_lp_client.h, which live in logos-protocol. That needed a target_include_directories on LOGOS_PROTOCOL_ROOT, and it does not resolve in this build: `fatal error: 'logos_codec.h' file not found`. The repo's own test target has been red on master since that merge. The right fix is not more include plumbing. The assertions were testing b64UrlEncode / bytesToJson, which this repo no longer defines — #117 moved them to their canonical home — so they moved with them, to logos-protocol tests/protocol/test_codec.cpp, in six cases covering more than the original did. Not replaced: a direct unit test of logos::jsonToBytes, the three-line lenient wrapper in logos_lp_client.h. It is built entirely on isTaggedBytes and b64UrlDecode, both now covered where they are defined, and testing it here would reintroduce exactly the cross-repo include this commit removes. Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Dario LipicarandClaude Opus 5
|
461cfed52d |
refactor: the LIDL codec exists once (#117)
* refactor: the LIDL codec exists once
The cdylib generator emitted its own copy of the codec — ~186 lines of
C++-emitting-C++ mirroring logos-protocol's logos_codec.h by hand. Every codec
fix had to be written twice or it silently only half-applied, which happened
twice in a row recently (routing scalars through the codec + signedness; then
accepting 3.0 while still rejecting 3.7).
It was worse than duplication. The two copies had DRIFTED — the emitted integer
decode gated on is_number() where the canonical one checked is_number_integer()
|| is_number_unsigned() — and logos_json.h's byte helpers were the same mangled
symbols with weak linkage and DIFFERENT bodies as logos_codec.h's, both reaching
one program (module TUs compiled one; liblogos_protocol.a carries TUs that
included the other). Which body won was down to link order.
logos_json.h goes back to its documented charter — "LogosMap/LogosList aliases
for impl classes", per its own CMakeLists — and loses 77 lines. jsonToBytes moves
beside its sibling jsonToStringVec in logos_lp_client.h, rebuilt on the canonical
isTaggedBytes/b64UrlDecode; it keeps its own narrow spelling because every lp
decoder is documented to yield the default-constructed value on a mismatch,
which neither bytesFromJson (throws) nor bytesFromJsonLenient (accepts more) does.
Emptying it rather than making it include logos_codec.h is deliberate: some
thirty alias-only include sites across the module repos get ZERO new includes,
and logos-cpp-sdkConfig's "only dependency is nlohmann_json" stays true.
With the clash gone the generic half is deletable. emitGeneratedCodec becomes
emitRecordCodecs: one logos::detail::Codec<::Rec, void> per declared record, and
nothing else. That residue is irreducible — a LIDL `type` is a per-contract
struct whose fields exist only in that module's header, and C++17 has no field
reflection. Nesting composes for free: Codec<std::vector<Blob>> and deeper come
from the shared half once Codec<::Blob> exists.
One asymmetry dies with it. The scalar bstr decode and the [bstr] element decode
were different functions with different strictness, so echoBytes("hi") succeeded
while echoBytesList(["hi"]) threw — inside one module, for the same type. They
are one function now.
Build wiring: ONE line, in this repo's own test CMake, using a variable
nix/tests.nix already supplies. Nothing in logos-module-builder, logos-qt-sdk, or
any module repo.
verified: cpp-sdk + protocol suites green; test_fullapi_cpp, test_fullapi_ext_cpp
and test_basic_module_cpp build; test-modules 176/176. Conformance delta is
exactly one cell, baselined first in logos-test-modules#31.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* chore: bump logos-protocol to the path-threaded bstr decoder
logos-protocol 4359557 (#33). Required by this branch, not incidental: deleting
the emitted codec swaps its path-carrying bstr decode for the canonical one, and
without #33 the canonical one reported "at value" instead of "[0].payload" —
losing the diagnostic exactly where a malformed bstr is hardest to find.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Dario LipicarandClaude Opus 5
|
c364133066 |
fix(cdylib): the emitted codec accepts a whole-valued float as an integer (#116)
Mirrors logos-protocol fix/integral-float-accept. The generator emits its OWN codec into <name>_types.h, so the rule has to be applied twice or half the platform disagrees — the same split that made the original scalar fix need two sites. #115 made the emitted integer codecs check signedness, and in doing so they started rejecting 3.0 as well as 3.7. Four test_basic_module_cpp cases pass a whole-valued double where the contract declares an integer, and they are right: JSON does not distinguish 3 from 3.0, and this same codec accepts an integral number for float64 on exactly that reasoning. A float now decodes as an integer when it has no fractional part and fits. 3.7 is still refused. Also adds <cmath> to the emitted include set for std::modf. verified: test-modules 176/176 with the four cases restored, conformance matrix unchanged at 170 pass / 2 xfail. Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Dario LipicarandClaude Opus 5
|
ff8c3003a4 |
fix(cdylib): typed scalars go through the codec, and the emitted codec checks signedness (#115)
* fix(cdylib): typed scalars go through the codec, and the codec checks signedness
The cdylib dispatch decoded composites with the generated codec but scalars with
a bare nlohmann accessor. Two silent conversions lived in that gap:
echoUint(-1) -> 18446744073709551615 (.get<uint64_t>() wraps)
echoInt(3.7) -> 3 (.get<int64_t>() truncates)
The Rust provider rejects both. So a contract both providers share answered
differently depending on which one a consumer resolved to, and one of the two
answers was a sign flip on a nominal value.
The reason this was left in place was circular, and it was written in the source:
the leniency "is pinned by the conformance matrix (`hostile/int/fractional`
expects 3 from 3.7 on this provider)". Those cells exist to DOCUMENT the
divergence — their own `why` text says the strict behaviour is correct. The
expectations moved with this change.
TWO sites, because fixing one relocates the bug rather than closing it:
* jsonArgToStd no longer special-cases int/uint/float64/bool/tstr — everything
typed goes through Codec<T>. `any` still passes through, since it declares
nothing to check against; bstr keeps its tagged-bytes decoder.
* the EMITTED codec (this generator writes its own copy into <name>_types.h,
separate from logos_codec.h) gated integers on `is_number()`, which admits
floats AND negatives. Routing scalars into it without fixing it would have
changed nothing. The integer specializations are now spelled out rather than
driven from the scalar table, because a category check is not enough for them.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* chore: bump logos-protocol to the signedness + sentinel fixes
logos-protocol c0df466 (#31):
* Codec<T> checks integer signedness and range, so a negative can no longer
wrap into an unsigned and a wide value can no longer truncate.
* the pending-call sentinel is matched by shape rather than key presence, so
a user map merely carrying that key no longer hangs the call.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Dario LipicarandClaude Opus 5
|
7fbdfe26ac |
chore: bump logos-protocol to the uint64 fixes (#114)
logos-protocol 8b8a358 (#30) — two places where a uint64 above int64max stopped being itself: * the universal -> Qt EVENT bridge converted with QJsonDocument::fromJson + QJsonValue::toVariant instead of the canonical helper the method path uses, so uintEvent(2^64-1) arrived as 1.8446744073709552e+19 while the equivalent method return was exact. The same bridge also failed to decode canonical tagged bytes into a QByteArray. * the plain (tcp/tcp_ssl) wire had no unsigned alternative in RpcValue, so the same value wrapped to -1 — silently, and independently in each direction. Retires M6 from the LIDL conformance matrix. Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Dario LipicarandClaude Opus 5
|
3d322bd315 |
fix(codegen): LIDL int/uint are 64-bit in the Qt spelling too (#113)
* fix(codegen): LIDL int/uint are 64-bit in the Qt spelling too lidlTypeToQt mapped BOTH `int` and `uint` to plain `int`. Everywhere else in the stack a LIDL int/uint is 64-bit — int64_t/uint64_t in C++ impls, i64/u64 in the Rust SDK — so the Qt spelling broke the one-type-per-LIDL-type rule and lost data: a Qt consumer reading a `uint` return got a SIGNED 32-bit value, so anything above 2^31 came back wrong and anything above 2^63 was never expressible. int -> qlonglong, uint -> qulonglong, and returnConversion() gains the matching accessors (toLongLong / toULongLong instead of toInt). qlonglong/qulonglong rather than qint64/quint64 so the generated introspection JSON uses the same names Qt's own metaobject normalisation produces — otherwise a cdylib module's generated `signature` and a legacy module's QMetaObject-derived one would disagree for the same LIDL type. Nothing looks these strings up: the only QMetaType::fromName call in the stack is for "LogosResult". This changes two generated surfaces: the Qt consumer wrapper signatures and the introspection JSON. Passing an int argument still converts implicitly, so callers keep compiling; code that assigns a wrapper's return into an `int` narrows and may warn, which is the bug being surfaced rather than a regression. Tests: 168/168, with the type-mapping and client-emitter expectations updated to the 64-bit spelling. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * feat(records): typed C++ structs for Qt consumers 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> * fix(codegen): teach the lp/std consumer wrappers the 64-bit spellings Caught while checking whether the SDKs are ready for the `any` migration, and it is a regression THIS BRANCH would otherwise have shipped. legacy/generator_lib.cpp generates the lp/std consumer wrappers a universal module uses to call its dependencies. It matches type names against an allow-list and falls back to QVariant for anything else: static const QSet<QString> known = { "void","bool","int","double","float","QString", … }; if (known.contains(base)) return base; return QString("QVariant"); Once lidlTypeToQt reports `qlonglong`/`qulonglong`, every LIDL int/uint method misses that list — so a typed `int` parameter would have silently become an opaque QVariant in those wrappers. Worse than the truncation this branch set out to fix, and invisible until someone read the generated header. Adds the two spellings to both allow-lists, plus the conversions they imply: QVariant->Qt (toLongLong / toULongLong), the std spellings (int64_t / uint64_t), the QVariant->std return path, the Qt-style return, and the default-value case. The existing `int` entries stay for legacy Qt plugins, whose QMetaObject still reports `int` for a 32-bit parameter. Tests: 171/171, with the allow-list pinned in both mapping test files — including that an unknown spelling still falls back to QVariant, so the fallback itself is not what regressed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * feat(records): typed structs for C++ dependency wrappers Closes the second record gap. The wrapper every C++ module actually gets for its dependencies comes from the LEGACY generator (`--dep <name>=<lidl>`), not the client-stub backend the previous commit taught about records — and there a contract's `type Status { ... }` reached the consumer as an untyped bag: QVariant on the Qt surface, LogosMap on the std/lp one. Worse than inconvenient for a `bstr` field: the caller received the canonical `{"_bytes": "..."}` envelope and had to know to unwrap it, while Rust and the stub backend handed back real bytes. Now, on all three api styles: struct Status { uint64_t port{}; std::vector<uint8_t> blob{}; }; Status getStatus(logos::CallError* err = nullptr); std::string describeStatus(const Status& s, ...); std::vector<Status> listStatuses(...); The struct is NESTED in the wrapper class (`InfoModule::Status`) because a module consuming two deps that each declare a `Status` includes both wrappers into one translation unit. Conversions are file-local statics in the generated .cpp, so a Qt-free module's own TUs still never see QVariant or nlohmann. Records reach parameters, returns, event callbacks, `[Record]` and `{tstr: Record}` — at any depth, with bytes tagged throughout. Same commit, the legacy path's half of the 64-bit fix: `lidlTypeExprToQtTypeName` mapped BOTH int and uint to `int` ("wire-as-int for now"), so a `uint` method on a dep reached a Qt consumer as a signed 32-bit value and a std/lp consumer as a signed int64_t. Now qlonglong/qulonglong, matching the spelling the other half of this PR gave the stub backend. `lpFromJsonExpr` grew the uint64_t branch it needed — without it a mistyped payload THREW out of nlohmann's implicit conversion instead of defaulting like every other scalar. Verified by generating a contract with a record, a record-of-records, a `uint` above 2^32 and a high-byte `bstr`, then COMPILING the output for qt/std/lp and round-tripping the emitted conversions: - `{"_bytes":"gAH_"}` at every depth, decoding back to the same bytes - 4294967296 intact through both directions - garbage/missing fields default rather than throw That compile is what caught the one real bug here: the container decode lambdas declared `__m`/`__j`, shadowing the record decoder's own locals, so a map-of-records field read from its own uninitialized local — it compiled with nothing but a -Wuninitialized warning. Locals are `__acc`/`__src` now, pinned by a test. Also: 8 generator tests (one asserting an empty record set leaves every byte of the output as it was), 179 total green; logos-test-modules builds and tests green against this generator. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(records): async record returns decoded a default-constructed struct Two correctness holes in the record work, both silent, found while scoping the cdylib provider side. 1. The async consumer overload emitted `qvariant_cast<Status>(v)` while the sync one emitted `StatusFromVariant(_result)`. The wire delivers a QVariantMap and no Q_DECLARE_METATYPE is emitted for the struct, so the cast does not fail — it returns a DEFAULT-CONSTRUCTED Status and the caller sees empty fields with no diagnostic. The sync path being correct is what makes it bad: the same call is right or wrong depending only on which overload the caller reached for. Async now decodes field by field through the same conversion. (The legacy dependency-wrapper generator already did this correctly — this was the experimental client-stub backend only.) 2. A record whose ONLY field is a tstr named `_bytes` is wire-identical to a canonical tagged byte string: `isTaggedBytes()` is checked before `is_object()` in both logos_codec.h and logos_json_convert.cpp, so such a record decodes as bytes and the struct silently disappears. The ambiguity is inherent to the tagged form — the codec's own comment says not to name a map key `_bytes` — but the generator can refuse to emit the one shape guaranteed to misdecode instead of leaving it to be found at runtime. Both front doors (the .lidl client-stub path and the --dep/--interface path) now reject it with a message naming the type and the fix. A second field disambiguates it (isTaggedBytes requires exactly one key), so that shape still generates — verified, not assumed. 181 tests, +2. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * feat(cdylib): records, [bstr], typed maps and nested composites on the C++ provider The C++ cdylib backend could express scalars, `[scalar]`, `any` and an untyped map. Everything else it rejected BY NAME — `[bstr]`, `[[int]]`, `{tstr: int}`, and records, which the impl-header parser could not even declare because it skipped `struct` outright. That is why the ext contract had to be Rust-only. Four changes, in the order they matter: typeSupported() recurses instead of whitelisting element names, which admits [bstr], [[int]], [Record] and [{tstr: T}] in one rule; a declared record is admitted; a map now REQUIRES a tstr key (it used to `return true` for any map and then silently flatten {int: tstr} to an untyped LogosMap, losing the key type). lidlTypeToStdCdylib() became total. Its `lidlTypeToStd` fallback answers QVariantList / QVariantMap — Qt names in a Qt-FREE translation unit — and only failed to appear because the gate rejected everything that reached it. Widening the gate made that fallback a live leak, so composites now recurse and never reach it. <name>_types.h new: the generated codec, recursive, with a FULL specialization for std::vector<uint8_t> that wins over the generic vector rule — which is what keeps a bstr tagged at any depth instead of becoming a plain array of numbers. One Codec specialization per declared record, field by field, with the field path in the error. impl_header_parser learned `struct` (two passes, because a record field may name another record and the type mapper only answers Named() for an already-registered name — one pass silently typed `Blob inner;` as `any`), std::map<std::string, T>, and recursion into vector elements so std::vector<Blob> is [Blob] rather than falling through to `any`. Records are only names the contract DECLARES: `void` is not a LIDL builtin, so `-> void` arrives as Named("void"), and treating every Named as a record is the exact trap that made the Rust generator emit `-> Void`. Two things the interface JSON got wrong, both found by running it: - it spelled a record `Blob` and a `[Record]` `QList<Blob>`. Those are the CONSUMER's names, correct in a generated wrapper where the struct exists — but this JSON is the module's getMethods(), read by the host to marshal a QVariant, and there is no metatype called `Blob`. The host SIGSEGV'd on the first call to any record method. A record IS a variant map at that boundary; lidlTypeToQtWire() says so. - the types header emitted the structs. Header-first, the author owns them and the contract was derived from those very declarations, so it was a redefinition. It emits forward declarations and the codec. Also: `jsonReturn` is set by the front end for any map return, which no longer implies the C++ type IS nlohmann::json now that a typed map is std::map<std::string, T> — checking the flag before the spelling emitted `result.dump()` on a std::map. The spelling decides. Scalars keep their nlohmann accessor verbatim rather than routing through the codec: `.get<int64_t>()` TRUNCATES a float instead of throwing, and the conformance matrix pins that leniency (hostile/int/fractional expects 3 from 3.7). Changing it would silently move behaviour something depends on. The pinned-rejection test for [bstr] is INVERTED rather than deleted — the cell it pinned still matters, only its answer changed — plus new tests for the non-tstr map key rejection and for declared-vs-undeclared records. 183 tests. Every existing module still builds; test_fullapi_cpp is unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(records): only structs the API mentions become contract types Teaching the impl-header parser to read `struct` (previous commit) published EVERY struct in a header as a contract `type`. Two production modules already carry private helpers: openmetrics-module struct ModuleSource (namespace scope, internal) logos-package-manager struct PendingAction (PRIVATE, inside the class) Both were being published — a module's interface changing as a side effect of an internal refactor, which is not something deriving a contract from a header may do. PendingAction was published WRONG as well: its fields carry trailing `// comments`, the field regex requires a line ending in ';', and the unmatched fields were silently dropped. A record with a partial field list is worse than no record, because it looks like a contract. A struct now earns its place by appearing in a method or event signature — transitively, since a published record's own fields may name others. Verified on the real headers: package-manager and openmetrics publish zero types again, while the ext provider keeps both Blob and Wrapper (Wrapper is reachable only through Blob's use in a signature). Trailing comments are stripped before the field match, so no field is dropped. Two tests over a fixture carrying both an internal namespace-scope struct and a private in-class one; 185 tests. test-modules and openmetrics both rebuild. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(doctests): the generator round-trip now shows 64-bit ints and typed records The two failing assertions in cpp-sdk-generator-roundtrip were documentation asserting the OLD behaviour, and both changes are the point of this branch: int record(int id, …) -> qlonglong record(qulonglong id, …) QVariant translate(QVariant p) -> Point translate(const Point& p, …) `record`'s `id` is a `uint64_t` in the impl header, so the old signature was handing a caller a SIGNED 32-bit value for a `uint` — the doc showed the bug. The surrounding prose was wrong too, not just the expectations, so both blocks are rewritten rather than patched: * Flow 3 now states the mapping as int->qlonglong / uint->qulonglong and says why (LIDL int/uint are int64_t/uint64_t in every other binding), pointing at `record` as the worked example. * The composite section claimed "records and optionals surface as QVariant". Records now generate a struct, `[Point]` a QList<Point> and `{tstr: Point}` a QMap<QString, Point>; maps of `any`, optionals and bare `any` still cross untyped and stay QVariant/QVariantMap — a record has a declared shape, those do not. The new text draws that line explicitly. Expectations added for `struct Point` and `Point bounds(const QList<Point>&…)` so the record path is pinned in the doc, not just described. Verified the way CI runs it — `--release-for logos-cpp-sdk=feat/qt-64bit-numerics`, which is what makes `{release}` resolve to this branch instead of master: 10 passed, 0 failed. (A plain local run builds master and is not representative — that is why it still showed the old signatures.) outputs/ regenerated; the diff also picks up unrelated pre-existing drift where the committed Markdown had fallen behind the spec. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Dario LipicarandClaude Opus 5
|
8a40a98322 |
feat(cdylib): support [bstr] — arrays of byte strings (#111)
A universal module could take or return a single blob (`bstr`) but not a list
of them: `std::vector<std::vector<uint8_t>>` parsed to `[bstr]`, which the
cdylib gate rejected by name. Authors had to flatten to hex or base64 strings
by hand. logos-execution-zone-module hit this on
send_generic_private_transaction(..., program_dependencies), whose dependency
ELFs are exactly a list of blobs.
The gate excluded `[bstr]` because the array path decodes with a blanket
`expr.get<inner>()`, and `[bstr]` elements arrive as the canonical tagged
{"_bytes": base64url} OBJECT — nlohmann refuses that, and a number-array
element would silently bypass the base64 decode. So admitting the type needed
a per-element codec, not just a whitelist entry.
Adds one, on top of the scalar codecs already emitted:
- lidlBytesListFromJson: element-wise lidlBytesFromJson, so each element may
independently be tagged, a plain string or a number array; a non-array arg
yields an empty list instead of throwing, matching the scalar decoder.
- lidlBytesListToJson: element-wise lidlBytesToJson, so a returned or emitted
list carries the tagged form per element instead of nested number arrays
that no consumer decodes as bytes.
Wired into all three places the type can appear — method params, method
returns, event payloads — and both helpers are gated (usesBytesArray /
hasBytesArrayEventParam) so a module that never carries a byte-string array
gains no unused static function, matching how the scalar encoder is gated.
Nothing outside this generator needed changing: lidlTypeToStd already spelled
`[bstr]` as std::vector<std::vector<uint8_t>>, the wire form is protocol's
existing tagged-bytes encoding, and consumers see `[bstr]` as QVariantList
exactly like `[int]` — with nested QByteArray preserved through
qvariantToNlohmann since logos-protocol#23.
Tests: 171/171. New coverage for the param decode, the return encode, the event
encode, and the unused-helper gating; the test that enshrined the rejection is
now an eligibility + tagging assertion.
Verified end to end, not just as generated text — a module with `[bstr]` as
param, return and event payload, driven through logoscore over the real
transport:
param : json:[{"_bytes":"AH-A_w"},{"_bytes":""},{"_bytes":"3q2-7w"}]
-> "3|4:0:255:510|0👎-1:0|4:222:239:824" (byte-exact; the 0x80
and 0xff bytes survive, and the empty element stays an element)
return : [{"_bytes":"AH-A_w"},{"_bytes":""},{"_bytes":"3q2-7w"}]
event : {"arg0":[{"_bytes":"AH-A_w"},{"_bytes":""},{"_bytes":"3q2-7w"}]}
And lez_core's real header now generates, decoding program_elf with the scalar
codec and program_dependencies with the list one.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
|
||
|
Dario LipicarandClaude Opus 5
|
2ac8e8fc17 |
chore: bump logos-protocol to the lp owner-thread fix (#28) (#110)
Picks up logos-protocol ae2f7e1: lp clients on a Qt-affine transport are constructed on the Qt main thread rather than on whichever thread makes the module's first outbound call, which previously left the QtRO node and socket on a thread with no event loop (every replica acquire then burned its full 20s timeout and returned an empty result). Hygiene only for this repo: `LpClient::ensure()` here already creates the client lazily and that stays as it is — the fix is entirely inside the protocol's lp_client_create. Module builds take their protocol from logos-module-builder's `follows`, so they do not depend on this pin; this keeps cpp-sdk's own lock and its tests on the same protocol as the rest of the stack. Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Dario LipicarandClaude Opus 4.8
|
2e31eeb1ac |
chore: bump logos-protocol to the owner-thread destroy fix (#109)
Picks up logos-protocol#27 (8ede8ec), which stops lp_client_destroy from deleting the LogosAPIClient on whatever thread released the last handle share. Destroying it off the owner thread tore the QtRO transport's socket notifiers down cross-thread and took the module process out with SIGSEGV; the destroy now defers to the owner via deleteLater(). Reproduced and fixed end-to-end under logoscore, 3/3 each way, with a control arm isolating that commit as the cause. This bump also crosses protocol#20 (group-shareable local sockets, stale-socket reaper, bind-failure detection) — this repo's pin was one release behind the other SDKs. Checks green: logos-cpp-sdk-tests. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Dario LipicarandClaude Opus 4.8
|
f3de5527e2 |
chore: bump logos-protocol to master (rejection token re-exchange #26) (#108)
Picks up logos-protocol#26 (ef24bd7): provider returns the structured unauthorized sentinel on a stale token; consumer drops it, re-runs requestModule and retries once. Standalone `nix flake check`: 168/168 pass. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Dario Lipicar
|
c3fa1b5ad3 |
chore: re-pin logos-protocol to master (LogosAPIConsumer handle cache) (#106)
Picks up logos-co/logos-protocol#24 (664b43f): LogosAPIConsumer caches the remote-object handle per name across sync + async calls, avoiding a per-call QtRO replica acquire. Consumer-side, ABI-compatible (appended virtual/member, C ABI untouched). |
||
|
Dario Lipicar
|
e8966bf7a9 |
fix(codegen): correct [T]-array arg packing and any-value return in the Qt client (#105)
* fix(codegen): pack Qt client args as one element each, not a spread list
The generated Qt client wrapper packed a method's arguments with
`QVariantList{a, b, ...}` (sync) and `QVariantList{...}` / `QVariantList() << a`
(async). For a QVariantList-typed argument -- every `[T]` list type (`[any]`,
`[int]`, `[uint]`, `[float64]`, `[bool]`) -- a braced `QVariantList{v}` and
`<< v` both CONCATENATE the list's elements into the args list, so
`echoList([1,2,3])` went out as three positional args instead of one array arg.
The receiver saw an arg-count mismatch and the list round-tripped empty; through
a UI->proxy->provider 2-hop it hung the call outright. This is the long-standing
"typed arrays empty over the Qt path" bug.
Fix both generators that emit the Qt client:
- legacy `generator_lib.cpp` (the production `logos-cpp-generator`): wrap each
arg in `QVariant::fromValue(...)` in the sync and async call sites.
- experimental `lidl_gen_client.cpp`: route both paths through the existing
`packVariantList` helper (which already wraps with `QVariant::fromValue`), the
same helper the event `trigger` path uses.
`QVariant::fromValue` does not double-wrap an already-QVariant (`any`) arg, and
scalars/QString/QVariantMap/QByteArray were never affected (they don't
concatenate). Empirically: `QVariantList{v}` / `<< v` give size 3 for a 3-element
list; the wrapped forms give size 1.
Tests: legacy generator_tests gain ListArgWrappedAsOneElement and update the
param-packing assertions to the wrapped form; experimental gains
ListArgIsPackedAsOneElement. 167/167 green.
* fix(codegen): pass `any` (QVariant) return through raw in the lp wrapper
The Qt-free (lp) client generator maps both `any` (QVariant) and the `{tstr:any}`
map (QVariantMap) to the same `LogosMap` std type, and decoded a `LogosMap`
return as `jv.is_object() ? jv : LogosMap::object()`. For a genuine map that is
a no-op, but for `any` it collapsed every NON-object value (a string, a number,
an array) to an empty object `{}`. A universal proxy forwarding `echoAny("x")`
through this wrapper therefore returned `{}` instead of `"x"` — the concrete
cross-version blocker (the UI's runMethods verified echoAny and got FAIL:echoAny
through the 2-hop).
`lpFromJsonExpr` still receives the original Qt type, so it can tell `any`
(mapReturnType == "QVariant") from the map (QVariantMap): pass `any` through
unchanged, keep the object coercion only for the map.
Test: MakeSourceTest.LpAnyReturnPassesThroughButMapForcesObject.
With this + the arg-spread fix, a UI drives the full method surface (incl.
echoAny and every array type) through a universal proxy 2-hop end to end.
|
||
|
Dario Lipicar
|
ad30010f80 | chore: bump logos-protocol to master (nested-bytes qvariantToNlohmann fix #23) (#104) | ||
|
Dario LipicarandClaude Opus 4.8
|
2f34804948 |
fix(codegen): handle bstr + composite-any types in cdylib + Qt wrappers (#103)
Three type-handling gaps surfaced by a module that exercises the full type surface (every method param/return + event param type): 1. cdylib method-param decode used lidlTypeToStd() for array params, which falls back to Qt containers (QVariantList) for [any] — undeclared in the Qt-free cdylib TU. Use the Qt-free lidlTypeToStdCdylib() so [any] decodes as LogosList. (lidl_gen_cdylib.cpp) 2. The Qt sync wrapper had no QByteArray return case, emitting a bare 'return _result;' (QVariant) for a bstr return — no implicit QVariant -> QByteArray conversion. Add toByteArray(). (generator_lib.cpp) 3. The Qt event-callback arg converter had no QByteArray case, so a bstr event param was delivered via .toString() to a std::function<void(QByteArray)>. Add toByteArray(). (generator_lib.cpp) Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Dario LipicarandClaude Opus 4.8
|
c7444bc29a |
Follow-ups to #100: lp-consumer bstr decode, Qt-free cdylib event types, binary-event coverage (#102)
* cdylib events: Qt-free types, and drop the unused bytes encoder Three follow-ups to the bstr event fix, all in the cdylib events sidecar -- a Qt-FREE translation unit: - An `any`/map event parameter was emitted as a bare QVariant/QVariantMap, which does not compile there. Spell those as their nlohmann aliases (LogosMap / LogosList) and pull in <logos_json.h> when they appear. - std::vector<std::vector<uint8_t>> fell through the impl-header parser's unknown-type fallback to `any`, so the cdylib gate admitted it and the generator then emitted QVariant. Parse it as `[bstr]` so the gate rejects it with a message naming the offending parameter. - The bytes encoder was emitted into every module's sidecar, leaving an unused static function (-Wunused-function) wherever no event carries binary data. Emit it only when a bstr event parameter exists. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * lp consumer: decode bstr into std::vector<uint8_t> The Qt-free (`lp`) consumer wrappers -- what every universal C++ module gets for its dependencies -- had no QByteArray in their type tables, so a `bstr` event parameter, method argument, or return degraded to QVariant and then to LogosMap. A consumer subscribing to a binary event was handed the raw tagged JSON object {"_bytes": "<base64url>"} instead of the bytes, with no generated decode. Teach the tables about QByteArray (-> std::vector<uint8_t>) and marshal it through the canonical tagged form in both directions: logos::bytesToJson on the way out, logos::jsonToBytes on the way in. Those live in logos_json.h -- Qt-free and protocol-free, so the generated wrappers and module code can share them. The Qt apiStyle already did this via QByteArray::toBase64/fromBase64. Without this, a subscriber written the obvious way -- onBinaryReady([](const std::string&, const std::vector<uint8_t>& payload) {...}) -- compiles (nlohmann::json has an implicit conversion operator) and then throws at runtime on every event, so the callback body silently never runs. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * tests: cover binary event payloads by value, not just by source text The regression test for #99 asserts on generated source text, so it stays green against an encoder that emits the wrong bytes. Add the value-level half: - tests/sdk/test_logos_json_bytes.cpp exercises the canonical tagged-bytes codec against the RFC 4648 vectors, the URL-safe alphabet, every len%3 tail group, embedded NULs and high bytes, a 109,447-byte payload (the size from #99), and the lenient/padded decode paths. - tests/experimental/test_lidl_gen_cdylib.cpp additionally pins the Qt-free spelling of JSON event payloads, the rejection of [bstr], and the omission of the bytes encoder from modules whose events carry no binary data. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * doctests: prove a binary event payload survives the round trip Neither doc-test covered bytes-in-an-event -- the gap #99 fell through. The generator round-trip carried `bstr` only as a method argument and return, and the composition doc-test, which is the one that actually runs two modules under logoscore and subscribes to an event, carried only a string. So a generator that dropped every bstr event argument kept both of them green. - cpp-sdk-module-composition: greeter_module gains a `blobReady(label, payload)` event and an `emitBlob(size)` method; orchestrator_module subscribes and reports the length AND a checksum of what it received. Length alone would not catch a corrupted payload -- a wrong alphabet round-trips to the same size. - cpp-sdk-generator-roundtrip: sensor_module gains a `capture(id, frame: bstr)` event, and a new step shows the generated event body encoding it through lidlBytesToJson rather than pushing it raw. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * logos_json.h: include <cstddef> for size_t The tagged-bytes codec uses size_t but relied on it arriving transitively through the other includes. Include <cstddef> directly so the header is self-contained. (Copilot review, PR #102.) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Santiago Galván
|
b60b230e66 | Fix binary payloads in cdylib events (#100) | ||
|
Dario LipicarandClaude Opus 4.8
|
d12a7bbb45 |
chore: bump logos-protocol to include plaintext-args log fix (#98)
Picks up logos-protocol 976bc7a (logos-co/logos-protocol#10), which stops ModuleProxy::callRemoteMethod from logging call arguments in plaintext. d5d58e7 (current pin) is the exact parent, so this is a one-commit bump. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
Khushboo-dev-cpp
|
350a2891e6 | chore: bump logos-protocol (#97) 0.2.0 | ||
|
Khushboo-dev-cpp
|
31b9d2bf5f | chore: bump logos-protocol (#95) |