Skip to content

feat(core): defmt::Format for every type the log macros format (#352, 1/3) - #358

Merged
lxsaah merged 1 commit into
feat/352-log-defmtfrom
fix/352-defmt-format
Oct 24, 2026
Merged

lxsaah merged 1 commit into
feat/352-log-defmtfrom
fix/352-defmt-format

Conversation

@lxsaah

@lxsaah lxsaah commented Oct 24, 2026

Copy link
Copy Markdown
Member

Description

PR 1 of 3 into feat/352-log-defmt for #352: the groundwork, so that log_*! can forward to defmt in PR 2.

How the scope was found: I temporarily added the defmt branch to the log_*! macros and built every crate that can build with defmt for thumbv7em (core in four feature combinations, MQTT, KNX, serial, TCP). The compiler then listed every argument type without defmt::Format. This PR covers core's share:

Type Solution
TransportError, CodecError, AuthError, FrameFault #[cfg_attr(feature = "defmt", derive(defmt::Format))]
DbError hand-written impl through Display (defmt::Display2Format)
SerializeFailure (pub(crate)) the same, through its existing Display
String, Vec<String>, Arc<str> core's defmt feature enables defmt/alloc

Why DbError isn't derived: its std-only variants carry io::Error / serde_json::Error, which don't implement Format. The workspace builds docs.rs with all-features = true (Cargo.toml:186), so std and defmt are on together there and a derive would break that build. Display2Format uses the thiserror text, so the defmt line matches the tracing/log line. It isn't interned, which is fine for error paths. This follows the existing hand-written impl for SerializeError (connector.rs).

Guard: a compile-time assertion in lib.rs requires Format for all of these types as soon as defmt (with connector-session) is on, so none can lose it before PR 2 uses them.

No behaviour change: nothing calls these impls until PR 2.

Left for PR 2 (found by the same build): the defmt branch in the macros, the __private re-export, and in aimdb-knx-connector a direct defmt dependency (defmt's macros expand to absolute defmt:: paths) plus defmt/ip_in_core (for core::net::SocketAddr). Also the three std-only crates (zenoh, sync, UDS) need to know the new defmt feature name, because of unexpected_cfgs in #[macro_export] macros.

Verified locally

  • All Makefile tests and clippy commands for aimdb-core.
  • Every thumbv7em check/clippy command in the Makefile for aimdb-core, aimdb-mqtt-connector, aimdb-knx-connector, aimdb-serial-connector and aimdb-tcp-connector.
  • Core with defmt on thumbv7em (alloc,connector-session,remote,defmt, alloc,defmt, alloc,observability,defmt).
  • cargo check / cargo doc -D warnings for aimdb-core --all-features (std and defmt together, as on docs.rs).

Related Issue

🤖 Generated with Claude Code

https://claude.ai/code/session_01YPDjQ947yKjLLAq3Xzgu3e

Groundwork for forwarding `log_*!` to defmt (#352): under core's `defmt`
feature, every argument type core's log lines format now implements
`defmt::Format`.

- `TransportError`, `CodecError`, `AuthError`, `FrameFault`: derived.
- `DbError`, `SerializeFailure`: through their `Display` impl
  (`defmt::Display2Format`). `DbError`'s `std`-only variants carry
  `io::Error` / `serde_json::Error`, which do not implement `Format`, and
  docs.rs builds with every feature on, so a derive would break that build.
- core's `defmt` feature enables `defmt/alloc`, for `String`, `Vec<String>`
  and `Arc<str>`.
- A compile-time assertion keeps all of them `Format` under `defmt`.

Found by building every defmt-capable crate for thumbv7em with the macro
branch in place. No behaviour change on its own.

Part of #352.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YPDjQ947yKjLLAq3Xzgu3e
@lxsaah
lxsaah merged commit 714a6f4 into feat/352-log-defmt Oct 24, 2026
4 checks passed
@lxsaah
lxsaah deleted the fix/352-defmt-format branch October 24, 2026 19:07
@lxsaah lxsaah mentioned this pull request Oct 24, 2026
3 of 5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant