Files
logos-plugin-qt/cpp/logos_qt_arg_decode.cpp
Dario Gabriel LipicarandClaude Opus 5 778b4c5fd2 feat: the Qt host runtime and the cdylib-glue generator
This repo was the Qt plugin BUILD backend — pure Nix functions plus a CMake
module, with no C++ target at all. But the two things a Qt host actually needs
at runtime lived in logos-qt-sdk, where they are neither a language wrapper over
the protocol C API nor codegen:

  LogosAPI / LogosAPIProvider   owns a LogosTransportHost per transport,
                                constructs ModuleProxy / ModuleHandshakeProxy,
                                publishes the handshake surface, seeds trust
                                anchors, injects the token validator
  LogosProviderBase             the base every generated provider derives
  PluginInterface               the Qt plugin loading contract
  the cdylib->Qt glue generator the emitter that wraps a language-neutral
                                cdylib in a Qt plugin

They move here, so "swap the plugin technology" is a one-repo change.

ADDITIVE: the sources are COPIED and logos-qt-sdk is untouched. Removing them
there now would turn nine downstream masters red at once; that comes later,
after consumers are repointed.

qt_provider_object (and logos_qt_arg_decode, which its QMetaObject dispatch
needs) is carried deliberately even though it is legacy: logos_api_provider
falls back to wrapping a plain QObject in it, and the modules that rely on that
have not been migrated yet. It goes once they are.

The generator links Qt Core and logos-lidl only — never logos-cpp-sdk. It needed
exactly one helper from that SDK's shared frontend, lidlToPascalCase (~12
lines), which is inlined instead, the same way logos-view-module does it. It
also REFUSES `--backend <anything but cdylib>` rather than ignoring the flag:
callers are migrating from a tool where --backend was required and dispatched
on, so silently treating `--backend qt` as cdylib would emit confidently wrong
artifacts with a zero exit.

`rawLib`, `lib` and `cmake-module` deliberately do not reference the new
derivations, so a consumer that only wants the Nix build functions never
realises a Qt/protocol build. Proven, not assumed: with both new inputs
overridden to a bogus flake, cmake-module and rawLib still evaluate while
logos-qt-host fails — so the override bites and the cheap outputs really never
touch it.

Behaviour preservation is the whole claim of a relocation, so it is measured:
the emitted glue is BYTE-IDENTICAL to logos-qt-generator --backend cdylib over
every one of the 20 .lidl contracts in the workspace, in both single and
concurrency:multi mode (40 pairs, exit codes included), and single vs multi do
differ from each other, so both code paths were really exercised. The built
liblogos_qt_host.a is byte-identical to liblogos_qt_sdk.a, exporting the same
390 symbols.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-12 21:46:35 -03:00

76 lines
3.2 KiB
C++

#include "logos_qt_arg_decode.h"
namespace logos {
namespace {
// One case per QMetaType the Qt type mapping can produce for a parameter.
// Each hands off to the SAME QtArgCodec<T> the generated dispatch uses, so the
// two provider sites cannot answer differently for the same argument.
template <class T>
QtArgVerdict decodeAs(const QVariant& in, const std::string& path, QVariant& out,
std::string& error)
{
try {
out = QVariant::fromValue(detail::QtArgCodec<T>::from(in, path));
return QtArgVerdict::Ok;
} catch (const CodecError& e) {
error = e.what();
return QtArgVerdict::Rejected;
}
}
} // namespace
QtArgVerdict qtArgDecode(const QVariant& in, QMetaType paramType,
const std::string& path, QVariant& out,
std::string& error)
{
switch (paramType.id()) {
case QMetaType::Bool: return decodeAs<bool>(in, path, out, error);
case QMetaType::Int: return decodeAs<int>(in, path, out, error);
case QMetaType::UInt: return decodeAs<unsigned int>(in, path, out, error);
case QMetaType::Short: return decodeAs<short>(in, path, out, error);
case QMetaType::UShort: return decodeAs<unsigned short>(in, path, out, error);
case QMetaType::Long: return decodeAs<long>(in, path, out, error);
case QMetaType::ULong: return decodeAs<unsigned long>(in, path, out, error);
case QMetaType::LongLong: return decodeAs<qlonglong>(in, path, out, error);
case QMetaType::ULongLong: return decodeAs<qulonglong>(in, path, out, error);
case QMetaType::Double: return decodeAs<double>(in, path, out, error);
case QMetaType::Float: return decodeAs<float>(in, path, out, error);
case QMetaType::QString: return decodeAs<QString>(in, path, out, error);
case QMetaType::QByteArray: return decodeAs<QByteArray>(in, path, out, error);
case QMetaType::QStringList: return decodeAs<QStringList>(in, path, out, error);
case QMetaType::QVariantList: return decodeAs<QVariantList>(in, path, out, error);
case QMetaType::QVariantMap: return decodeAs<QVariantMap>(in, path, out, error);
case QMetaType::QJsonArray: return decodeAs<QJsonArray>(in, path, out, error);
case QMetaType::QJsonObject: return decodeAs<QJsonObject>(in, path, out, error);
// `any`, QUrl, QChar, enums, pointers, LogosResult, anything a module
// author invented: no LIDL counterpart, so no rule to check against. The
// caller keeps whatever it did before — see the header comment.
default:
return QtArgVerdict::Unchecked;
}
}
nlohmann::json dispatchFailedJson(const std::string& origin,
const std::string& message)
{
return nlohmann::json{{"code", "dispatch_failed"},
{"message", message},
{"origin", origin}};
}
QVariant dispatchFailedVariant(const QString& origin, const QString& message)
{
QVariantMap m;
m.insert(QStringLiteral("code"), QStringLiteral("dispatch_failed"));
m.insert(QStringLiteral("message"), message);
m.insert(QStringLiteral("origin"), origin);
return m;
}
} // namespace logos