Error type change doesn't cause a semver fail

Is this about an existing lint, or proposing a new one?

new

Known issues that might be causing this

[ ] Is the item that should have been flagged originating from another crate, or from a re-export of such an item? (#638)
[X] Is the issue related to a change in the type of a field, function parameter, generic, or trait bound? (#149)
[ ] If you're proposing a new lint, is it already part of our lint wishlist? (#5)

Steps to reproduce the bug with the above code

pub fn foo() -> Result<(), u32> { ... }

To:

pub fn foo() -> Result<(), String> { ... }

Actual Behaviour

No semver issues are found

Expected Behaviour

A semver breakeage should be reported

Generated System Information

System information:

Software version

cargo-semver-checks 0.36.0

Operating system

Linux 6.6.63

Command-line

/home/jalil/.local/share/cargo/bin/cargo-semver-checks semver-checks --bugreport

cargo version

> cargo -V
cargo 1.85.0-nightly (4c39aaff6 2024-11-25)

Compile time information

Profile: release
Target triple: x86_64-unknown-linux-gnu
Family: unix
OS: linux
Architecture: x86_64
Pointer width: 64
Endian: little
CPU features: fxsr,sse,sse2
Host: x86_64-unknown-linux-gnu

Cargo build configuration:

Build Configuration

No configuration, default cargo new --lib project basically.

Additional Context

I found this while working on https://github.com/scontain/sgx-quote. I changed the parser from nom to winnow, this is mostly an implementation detail, but the nom error was directly returned, this error no longer implemented Display or Debug (I don't remember which) so it couldn't be printed anymore.

obi1kenobi / cargo-semver-checks

Error type change doesn't cause a semver fail #1005