defmt-rtt: Update to critical-section 1.0

[Dirbaio]

This is a breaking change, because 1.0 no longer supplies any critical section implementation by default. The user has to opt-in to one instead (for example, by enabling the critical-section-single-core feature in cortex-m: rust-embedded/cortex-m#447).

Thankfully it needs bumping only defmt-rtt, and not defmt. So it won't cause the painful ecosystem split like the defmt 0.2 -> 0.3 update.

TODO before merging:

• Wait for critical-section 1.0 release v1.0.0 release rust-embedded/critical-section#19

[Urhengulas]

Thank you for the PR. Is there the possibility to make defmt-rtt enable the critical-section-single-core feature or does it always need to be done by the end user?

[Dirbaio]

Is there the possibility to make defmt-rtt enable the critical-section-single-core feature or does it always need to be done by the end user?

Has to be done by the end user.

They might be using a multicore chip, in which case using cortex-m/critical-section-single-core would be unsound. They'd need to use another impl, likely from the chip's HAL, using spinlocks to sync the multiple cores. rp2040-hal has one like this, for example.

Or they might not be using cortex-m at all :)

If defmt-rtt force-enables cortex-m/critical-section-single-core, the user can't use other critical section implementations at all (enabling 2 impls on the same binary intentionally causes linking to fail).

[Urhengulas]

There is a small concern of getting the defmt-rtt and defmt version out of sync, which might be confusing to users. But I think we can resolve this soonish.

Additionally, can you please add a section explaining the need to opt-in to a implementation to the docs.rs docs (the doc-comment in the beginning of lib.rs).

[Dirbaio]

@Urhengulas

There is a small concern of getting the defmt-rtt and defmt version out of sync, which might be confusing to users.

This is unavoidable if you want to keep compatibility in the main defmt crate. Updating defmt is super problematic. You can't mix major versions of it in the same binary, so if a lib you want to use uses defmt 0.3 you're stuck on that version. This is not a problem for defmt-rtt. It's only used from the main binary, so the end user chooses the version, which can be defmt-rtt 0.4 which is compatible with defmt 0.3.

But I think we can resolve this soonish.

I hope it doesn't mean defmt 0.4, right? 😰

Additionally, can you please add a section explaining the need to opt-in to a implementation to the docs.rs docs (the doc-comment in the beginning of lib.rs).

Done!

[Urhengulas]

Additionally, can you please add a section explaining the need to opt-in to a implementation to the docs.rs docs (the doc-comment in the beginning of lib.rs).

Done!

Thanks 😄

I hope it doesn't mean defmt 0.4, right? 😰

No no. We want to avoid that as well. We were just thinking how to make it easier for the users. We decided that it is good enough if we document which defmt and defmt-rtt versions are compatible with one another.

[Urhengulas]

bors r+

[bors]

Build succeeded:

• ci