Skip to content
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

Open
3 tasks done
nbigaouette opened this issue Nov 4, 2024 · 6 comments
Labels
A-lint Area: new or existing lint C-enhancement Category: raise the bar on expectations

Comments

@nbigaouette
Copy link

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

  • 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

Going from:

pub trait MyTrait {
    fn method(&self);
}

pub struct MyStruct {}

impl MyTrait for MyStruct {
    fn method(&self) {}
}

to:

pub trait MyTrait {
    fn method(&self);
}

pub struct MyStruct {}

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

#### Software version

cargo-semver-checks 0.31.0

#### Operating system

macOS 14.7 (Darwin 23.6.0)

#### Command-line

```bash
/Users/nbigaouette/.cargo/bin/cargo-semver-checks semver-checks --bugreport

cargo version

> cargo -V
cargo 1.82.0 (8f40fc59f 2024-08-21)

Compile time information

  • Profile: release
  • Target triple: x86_64-apple-darwin
  • Family: unix
  • OS: macos
  • Architecture: x86_64
  • Pointer width: 64
  • Endian: little
  • CPU features: cmpxchg16b,fxsr,sse,sse2,sse3,sse4.1,ssse3
  • Host: x86_64-apple-darwin

### Build Configuration

_No response_

### Additional Context

_No response_
@nbigaouette nbigaouette added A-lint Area: new or existing lint C-enhancement Category: raise the bar on expectations labels Nov 4, 2024
@nbigaouette
Copy link
Author

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 .ron file though.

@obi1kenobi
Copy link
Owner

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.

@tpoliaw
Copy link

tpoliaw commented Nov 22, 2024

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

@obi1kenobi
Copy link
Owner

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

@tpoliaw
Copy link

tpoliaw commented Nov 25, 2024

I'm happy to have a look at it but probably won't be for a few days. Will join the discord.

@obi1kenobi
Copy link
Owner

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 🙌

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lint Area: new or existing lint C-enhancement Category: raise the bar on expectations
Projects
None yet
Development

No branches or pull requests

3 participants