-
-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possible false-negative: Removing a manual trait implementation should be a breaking change #990
Comments
I searched for other lints that are supposed to check this but couldn't find any. I did start to add a new lint. Not sure how to build the |
Thanks for opening this and looking into writing a new lint! This is definitely breaking, nice catch 👍 I'm currently travelling and largely AFK until later this week, but I'd recommend two things:
It might also be a good idea to get used to lint-writing by first writing an easier lint that is very similar to another already-implemented lint. That way you can do a side-by-side comparison with an already-merged PR that adds a new lint, and can focus on just tweaking the lint logic and test cases to fit the new case. For example, #946 has one case already implemented and merged, and the remaining cases are very similar. After you're familiarized with the lint-writing process that way, you could circle back to this lint and implement it more easily. |
Possibly related to this, keeping the trait impl but tightening the bounds (so that it is no longer implemented for some types). eg from impl<T> From<T> for Foo {...} to impl<T: 'static> From<T> for Foo {...} This caused a breaking change in async-graphql/async-graphql#1634 (not my project) that I can't get to be flagged by cargo-semver-checks |
Neat, thank you for the repro and for sharing a real-world case where it happened. With the latest schema updates as of a week or two ago, I think it's possible to write a lint for "adding new lifetime bound to a generic parameter." Might you be interested in trying your hand at lint-writing @tpoliaw? I'd be happy to point you in the right direction if so — the time commitment including onboarding time is ~1hr. You're also welcome to join our community Discord if you'd like: https://discord.gg/ywEqqAwq |
I'm happy to have a look at it but probably won't be for a few days. Will join the discord. |
Awesome! The CONTRIBUTING doc should have the steps to get started, and feel free to ask questions in the Discord -- lots of people who have already written lints are there and we'd all be happy to help 🙌 |
Is this about an existing lint, or proposing a new one?
Deleting the manual implementation of a trait for a type does not trigger a sember-checks error.
Known issues that might be causing this
Steps to reproduce the bug with the above code
Going from:
to:
is not considered a breaking change by cargo-semver-checks right now. I think it should be?
Actual Behaviour
cargo-semver-checks
accepts the removal as non-breaking change.Expected Behaviour
cargo-semver-checks
reporting a semver breaking change error.Generated System Information
cargo version
Compile time information
The text was updated successfully, but these errors were encountered: