test(nexus): no_std compile-gate for derive macro output (#304)#305
Merged
Conversation
#279 (PR #303) made the kernel no_std and added flake gates that build it `--no-default-features` for thumbv7em + wasm32. Those prove the *core* is no_std, but never compile the *output* of `#[nexus::aggregate]` / `#[derive(DomainEvent)]` for a no_std target — the macro source was only grepped for `std::`, which is weak. Add `nexus-nostd-smoketest`: a `#![no_std]` crate defining an aggregate via both macros + `Handle` impls, entirely in `core` (`Events<E, 0>`, no allocator). Both flake gates now also build it `--features derive` for thumbv7em + wasm32, so a macro emitting a `std::` path fails the bare-metal build. The probe lives behind the `derive` feature; `nexus`/`thiserror` are optional and pulled only by it (`nexus/derive` is additive, not `nexus/std`). Excluded from workspace-hack (like `nexus`) so no std edge reaches the bare-metal build. Logic correctness stays covered on the host by the nexus-cross-crate-test suite — this is a compile probe. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #304.
Why
#279 (PR #303) made the
nexuskernelno_stdand added flake gates (nexus-nostd= thumbv7em,nexus-wasm) that build the kernel bare (--no-default-features). Those prove the core compiles no_std, but they never compile the output of#[nexus::aggregate]/#[derive(DomainEvent)]for a no_std target — during #279 the macro source was only grepped forstd::(weak). If a macro emits astd::path, a no_std consumer (Bombay-SDK "KERI on phone") breaks and we only find out downstream. The derive-on-no_std guarantee is what the IoT/embedded README claim rests on.What
New crate
nexus-nostd-smoketest:src/smoke.rs— a real#![no_std]aggregate using both#[nexus::aggregate]and#[derive(DomainEvent)]plus twoHandleimpls, entirely incore:[u8; 8]id +core::fmt::Display,Events<E, 0>(single-event, no allocator),thiserrorno_std error.drive()instantiates the monomorphisedAggregateRootdriver methods so a std leak in any of them surfaces at compile time on the target.src/lib.rs—#![no_std]; the probe lives behind#[cfg(feature = "derive")], so--no-default-featuresis a trivially-empty lib and--features derivecompiles the macro output.Cargo.toml—nexus+thiserroroptional, pulled only by thederivefeature (forwardsnexus/derive, notnexus/std)..config/hakari.toml— added to[final-excludes].workspace-members(same mechanism asnexus) so no stdworkspace-hackedge reaches the bare-metal build.flake.nix— bothnexus-nostdandnexus-wasmgates now alsocargo build -p nexus-nostd-smoketest ... --no-default-features --features derive.Acceptance
#![no_std]crate using the derive macros compiles forthumbv7em-none-eabihf+wasm32-unknown-unknownundernix flake checkstd::path (verified: a dangling symbol reference reddened the thumbv7em build until fixed)The optional
testing-fixture + alloc target (issue path #2) is deferred to a follow-up, as the acceptance criteria mark it optional; it needs a#[global_allocator]and is a separate, larger piece.The macro output was already core-clean — this lands as a regression guard, locking in a property #279 established but never compile-tested.
🤖 Generated with Claude Code