#[jedem::export] on a bare fn or a mod, not only an impl

[zmaril]

Stacked on #6. Item 6.

A crate exporting free functions had to invent a type for them to hang off —
pub struct Jawohl; in jawohl's case, conveying nothing and existing only
because the macro demanded an impl. Every consumer was writing one.

#[jedem::export] pub fn greet(name: &str) -> String { … }
#[jedem::export] pub mod arithmetic { pub fn add(a: i64, b: i64) -> i64 { … } }
#[jedem::export] impl Greeter { pub fn greet(name: &str) -> String { … } }

The interesting part: making surface! read uniformly

An impl exposes an associated Type::JEDEM_INTERFACE. A bare fn has no type
to hang one on. My first attempt had surface! resolve between
differently-named constants — which Rust macros cannot do: there is no "try
this path, else that one."

The fix uses a property of the language rather than fighting it. Rust keeps
modules and functions in separate namespaces, so a module named after a
function can carry that function's descriptor without shadowing it:

• a bare fn greet emits a hidden mod greet holding JEDEM_INTERFACE
• a mod gets the constant injected into its own body
• an impl keeps its associated constant

All three are then reached identically as Path::JEDEM_INTERFACE, so the
surface list is uniform and no resolution is needed at all.

One lowering path, three forms

The op-lowering that was inline in the impl expansion is extracted to a shared
lower_fn, so the forms cannot drift apart in what they capture — doc comments,
name pins, borrowed parameters, inferred fallibility.

Private functions in an exported module are skipped rather than exported, and
mod foo; without a body is a clear error rather than silence.

Tests

Six, including one that puts all three forms in a single surface and asserts the
generated call paths: a bare fn calls core::shout, a mod
core::arithmetic::add, a type core::Hello::greet.

Next: Box<dyn Error>, then #[derive(Enum)].

🤖 Generated with Claude Code

https://claude.ai/code/session_01HsDxLrGdx6nPaXkVEWkNvS