Release tracking for cortex-m 0.7.8 and related packages

[wt]

This is here to track the work items for preparing release of cortex-m 0.7.8 and any other related packages.

• Update changelog
• Perform semver-checks (cargo semver-checks --default-features)
• Bump version

[jannic]

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.

[wt]

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.

[wt]

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?

[wt]

Filed obi1kenobi/cargo-semver-checks#1618 on the false positive.

[thejpster]

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.

[jannic]

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.