Refactor fmt modules into a single shared embassy_fmt crate

[rukai]

advantages:

• reduces duplication
• the #[macro_use] extern crate embassy_fmt ensure that we always use the defmt macros over the space expensive core macros.
  • previously the best we could do was use crate::fmt::{unreachable, *}; which will import unreachable and give a compile error if any formatting macros are used but not manually imported. But I was accidentally deleting these because of the unused warnings and I didnt realize they create a helpful compiler error instead of using a core format macro.
• the current fmt module implementation has really strange repercussions for importing. the pub used macros are imported into the fmt module while the new macro_rules macros have a global scope. This means the macros are accessible at different paths depending on if the defmt feature is enabled or not. There are two ways to resolve this issue:
  • move the macros to a seperate crate (the method I chose here)
  • enable the pub_macro_rules nightly feature Tracking Issue for #![feature(pub_macro_rules)] rust-lang/rust#78855

disadvantages:

• introduces a new nightly feature requirement: namespaced-features

We could potentially provide embassy_fmt as a wrapper over defmt/log for end users but for now its just considered an implementation detail.
I havent changed stm32 to use it yet, I plan to do that in a follow up PR which will also add a .cargo/config and fix the warnings for stm32.

[rukai]

btw this PR reduces the size of most of the nrf examples by 20K.

We could certainly achieve this by careful manual inspection but it was made trivial by #[macro_use] extern crate embassy_fmt

[rukai]

I realized how to do this without namespaced-features, so i've removed it. (in hindsight it was pretty obvious)
It makes the features we expose a little more confusing but I think its worth it to avoid reintroducing namespaced-features.
I've also changed stm32 to use the new embassy_fmt crate.

[Dirbaio]

Sorry for taking so long to get back to you on this 😓

This fmt stuff is a very very hairy topic. I do agree the current solution is very suboptimal, however it's been changed many times already in the past and it seems all solutions that we find have some downside :(

The embassy-fmt crate approach also has some:

• If we rename the defmt feature to defmt-enable, the user can accidentally enable defmt instead, which will enable the optional dependency but not actually use it for logging.
• #[macro_use] extern crate foo is the Rust 2015 way of importing macros from another crate. It's accidentally convenient, as it puts the macros in-scope in the entire local crate, but I think its use is somewhat discouraged now.
• proc macros are not friendly to reexporting. defmt macros emit code that does defmt::blahblah. This code gets parsed in the calling crate's context, so defmt needs to be in scope there. This causes problems if only some crates have defmt enabled. Try this: edit embassy-nrf-examples/Cargo.toml then remove defmt feature from embassy-nrf, but leave it in for embassy. Build then fails, because embassy enables embassy-fmt/defmt. embassy-nrf then calls info! or whatever, which emits code that does defmt::blahblah, but defmt is not resolved in embassy-nrf because the optional dep is not enabled there.

I think due to the last point we're stuck with copypasting a fmt.rs to all the crates, so all the macroing is done in-crate to not reexport proc macros. The how the fmt.rs works is definitely improvable though.

For example, to avoid "unused import" warnings depending on log/defmt features maybe all macros should be macro_rules! that call defmt, log, core, or nothing? Then no use is needed at all in all cases I think.

[rukai]

thanks for the feedback!
I'll do some more investigation on the problem and get back to this in a week or two.

[Dirbaio]

With #227 the unfixable warnings should be gone.

Thank you @rukai for the push and trying out different solutions!