Release tracking for cortex-m 0.7.8 and related packages #639

Activity

1. jannic commented on Apr 2, 2026

   

   jannic

   on Apr 2, 2026

   Member

   More actions

   To run cargo semver-checks with --target options, I had to use a patched version of cargo-semver-checks, removing the --cap-lints=allow option from src/data_generation/generate.rs. (See https://github.com/rust-embedded/cortex-m/pull/422/changes for an explanation why this option doesn't work correctly.)

   With that change, the only issue I found was this one:

   --- warning repr_c_plain_struct_fields_reordered: struct fields reordered in repr(C) struct ---
   
   Description:
   A public repr(C) struct had its fields reordered. This can change the struct's memory layout, possibly breaking FFI use cases that depend on field position and order.
           ref: https://doc.rust-lang.org/reference/type-layout.html#reprc-structs
          impl: https://github.com/obi1kenobi/cargo-semver-checks/tree/v0.47.0/src/lints/repr_c_plain_struct_fields_reordered.ron
   
   Failed in:
     RegisterBlock.ipr moved from position 11 to 13, in /home/jan/arm/cortex-m/cortex-m/src/peripheral/nvic.rs:61
     RegisterBlock.stir moved from position 13 to 15, in /home/jan/arm/cortex-m/cortex-m/src/peripheral/nvic.rs:82
   

   (with slight variations depending on the selected target)

   I think this is a false positive: The change to that struct was introduced by https://github.com/rust-embedded/cortex-m/pull/422/changes, and that pull request carefully adjusts the padding so the fields stay in fixed locations.
2. wt commented on Apr 2, 2026

   

   wt

   on Apr 2, 2026

   Last edited by wt

   ContributorAuthor

   More actions

   Thanks for running this analysis, @jannic.

   I think this is a false positive: The change to that struct was introduced by https://github.com/rust-embedded/cortex-m/pull/422/changes, and that pull request carefully adjusts the padding so the fields stay in fixed locations.

   This does appear to be a false positive.
3. wt commented on Apr 3, 2026

   

   wt

   on Apr 3, 2026

   ContributorAuthor

   More actions

   There are also some problems that only appear to affect non-arm platforms, which are only supported in order to run clippy. Can we ignore those alleged semver problems? One example is this:

   --- failure module_missing: pub module removed or renamed ---
   
   Description:
   A publicly-visible module cannot be imported by its prior path. A `pub use` may have been removed, or the module may have been renamed, removed, or made non-public.
           ref: https://doc.rust-lang.org/cargo/reference/semver.html#item-remove
          impl: https://github.com/obi1kenobi/cargo-semver-checks/tree/v0.47.0/src/lints/module_missing.ron
   
   Failed in:
     mod cortex_m::register::basepri, previously in file /home/wt/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/cortex-m-0.7.7/src/register/basepri.rs:1
     mod cortex_m::register::faultmask, previously in file /home/wt/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/cortex-m-0.7.7/src/register/faultmask.rs:1
     mod cortex_m::register::basepri_max, previously in file /home/wt/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/cortex-m-0.7.7/src/register/basepri_max.rs:1
   

   These are referring to modules that are only relevant on certain cores. For example, the faultmask.rs module is not importable on x86_64. This functionally doesn't really matter since it isn't a supported platform.

   I think that one way to fix this might be to change the line at

   cortex-m/cortex-m/src/register/mod.rs

   Line 41 in 6baaf6a

   #[cfg(any(armv7m, armv8m_main))]

   to something like this:

   #[cfg(any(not(any(thumbv8m.main-none-eabihf, all_other supported targets)),any(armv7m, armv8m_main)))]

   That a lot of boilerplate to support clippy on the non-target platforms, so I guess we could wrap that in a macro. Something like:

   #[cortex_m_supported_arch(any(armv7m, armv8m_main))]

   I don't love that name, but I hope you get the idea. This macro would expand to the above thing to make all modules importable on none-supported targets for the purpose of running clippy.

   Is that what we want?
4. wt commented on Apr 3, 2026

   

   wt

   on Apr 3, 2026

   ContributorAuthor

   More actions

   Filed obi1kenobi/cargo-semver-checks#1618 on the false positive.
5. thejpster commented on Apr 3, 2026

   

   thejpster

   on Apr 3, 2026

   Contributor

   More actions

   I don't think this really matters as a breaking change, so I'd be inclined to ignore it for now and only give it more consideration in the highly unlikely event that someone complains. I certainly don't think it's worth that level of complication with macros.
6. jannic commented on Apr 7, 2026

   

   jannic

   on Apr 7, 2026

   Member

   More actions

   Looking through git log --oneline d5fb6c30e3a2a9d0e371965dc32687429bc5487f..HEAD cortex-m, I found these two changes that are not yet mentioned in the CHANGELOG.md, and probably should be added:

   • 1be630f Expose configuration of the SEVONPEND SCR bit (Expose configuration of the SEVONPEND bit within the System Control Register (SCR) #539)
   • 5573370 cortex-m: add support for embedded-hal 1.0 delays (cortex-m: add support for embedded-hal 1.0 delays #504)

   And maybe the asm changes you made, Wren? They shouldn't affect users of the crate, but still are a significant code quality improvement and worth mentioning.
7. wt

   added 2 commits that reference this issue on Apr 11, 2026

   Update the cortex-m unreleased changelog.

   ...

   ce96784

   Update the cortex-m unreleased changelog.

   ...

   dd3ee49
8. jonathanpallant commented on Sep 29, 2026

   

   jonathanpallant

   on Sep 29, 2026

   Contributor

   More actions

   we've since released cortex-m 0.7.9
9. jonathanpallant

   closed this as completedon Sep 29, 2026