Open sosthene-nitrokey opened 9 months ago
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.
Steps to reproduce the bug with the above code
Baseline
Patch update
Actual Behaviour
Cargo semver-checks raises an error:
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 onA
.The surprising part is that it works if the type alias fully forwards the generics:
baseline
patch update
Generated System Information
Software version
cargo-semver-checks 0.26.0 (0d1e24f)
Operating system
Linux 6.6.7-arch1-1
Command-line
cargo version
Compile time information
Build Configuration
No response
Additional Context
No response