Error type change doesn't cause a semver fail

[jalil-salame]

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)
• 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]

Yeah, we can't catch any type changes like this at the moment. We're making progress toward it, albeit slowly.