obi1kenobi / cargo-semver-checks

Scan your Rust crate for semver violations.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

False positive when replacing a struct with a type alias to a generic struct

sosthene-nitrokey opened this issue · comments

Steps to reproduce the bug with the above code

Baseline

pub struct B(usize);

Patch update

pub struct A<T>;
pub type B = A<usize>;

Actual Behaviour

Cargo semver-checks raises an error:

--- failure struct_missing: pub struct removed or renamed ---

Description:
A publicly-visible struct cannot be imported by its prior path. A `pub use` may have been removed, or the struct itself may have been renamed or removed entirely.
        ref: https://doc.rust-lang.org/cargo/reference/semver.html#item-remove
       impl: https://github.com/obi1kenobi/cargo-semver-checks/tree/v0.26.0/src/lints/struct_missing.ron

Failed in:
  struct crate_a::B, previously in file /tmp/crate-b/src/lib.rs:5
       Final [   0.008s] semver requires new major version: 1 major and 0 minor checks failed

Expected Behaviour

No error should be found. Unless I'm mistaken, this does not change how B can be used as long as the proper method and trait implementations are available on A.

The surprising part is that it works if the type alias fully forwards the generics:

baseline

pub struct B<T>(T);

patch update

pub struct A<T>;
pub type B<T> = A<T>;

Generated System Information

Software version

cargo-semver-checks 0.26.0 (0d1e24f)

Operating system

Linux 6.6.7-arch1-1

Command-line

/usr/bin/cargo-semver-checks semver-checks --bugreport 

cargo version

> cargo -V 
cargo 1.74.1 (ecb9851af 2023-10-18)

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

Build Configuration

No response

Additional Context

No response

Thanks for the report. Yeah, sadly we don't currently have a full model for type aliases and that leads to this kind of false-positive.

As you point out, our current implementation can only "see" and analyze type aliases that are direct renames of a type that already exists within the same crate. This works for type parameters, lifetimes, const generics, and any combination of them, and we even have extensive tests to make sure it keeps working:
https://github.com/obi1kenobi/trustfall-rustdoc-adapter/blob/rustdoc-v27/test_crates/pub_generic_type_alias_reexport/src/lib.rs

Unfortunately, in the current simplified model, any type aliases that are not just a rename are ignored. This is buggy behavior, as you correctly point out.

Adding the simplified model was the outcome of a sponsorship grant for the project, and tbh even with the simplifications it was a pain to build 😅 I'm hoping to get more GitHub sponsorships so I can focus on making the fundamental improvements necessary to address this issue and similar ones like it.