Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement defmt::Format for Error #11

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

dbrgn
Copy link
Contributor

@dbrgn dbrgn commented Oct 24, 2022

This allows printing erorrs with defmt. Really helpful for debugging.

Atat already implements this trait for their errors.

@dbrgn
Copy link
Contributor Author

dbrgn commented Oct 24, 2022

Uhh, this change isn't compatible with --all-features. I guess we need separate CI steps for log and defmt.

I'll have to change that on another day. (Alternatively, feel free to push to my branch if you want to take over.)

@@ -124,6 +124,34 @@ pub enum Error {
TimerError,
}

#[cfg(feature = "defmt")]
impl defmt::Format for Error {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are there any reasons against the use of derive?

#[cfg_attr(feature = "defmt", derive(defmt::Format))]

However, I have to admit that I have not looked at the output of cargo expand and of course there could be good reasons for a manual implementation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I simply wasn't aware that a derive macro exists for defmt 🙂 I'll test the output differences in my project sometime. (I haven't figured out how to convert defmt writes to a string on regular std-Rust on Linux...)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems this is not possible currently: knurling-rs/defmt#463

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have you had a chance to test the derive? If not, I'm also fine with the current implementation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, not yet. I'll try to take a look again soon.

run: cargo build --release --features strict

- name: Build in strict mode with log feature
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My first intuition would have been to implement the features as a matrix axis. But that would have made too much overhead, and so it is nice and lean. 👍

Copy link
Contributor Author

@dbrgn dbrgn Oct 27, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think a matrix makes sense if we have even more distinct features, but for now this is probably the simplest and fastest way (because build cache is shared).

@marius-meissner
Copy link
Member

Any updates on this?
Don't want to put any pressure, just for avoiding zombie PRs, which fall to far behind.

If a test of derive is not possible due to time constraints, I would be happy to merge the PR in its current state and switch to derive later if necessary.

@dbrgn
Copy link
Contributor Author

dbrgn commented Nov 23, 2023

Hey @marius-meissner, somehow I missed your reply.

I'm a bit low on free time, and am not currently working on the project anymore where I integrated esp-at-nal. Thus, if you'd be willing to merge as-is, that's probably the best option for now 🙂

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.

2 participants