-
-
Notifications
You must be signed in to change notification settings - Fork 79
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
False positive for the trait_method_added
lint with diesel
#953
Comments
Thanks for the report, and sorry for the inconvenience. I have to say I've never seen a bound like the pub trait Connection: SimpleConnection + Sized + Send
where
Self: ConnectionSealed, from https://docs.diesel.rs/2.2.x/src/diesel/connection/mod.rs.html#212-217 Just so I make sure we get this right in our test suite, is that semantically different than writing pub trait Connection: SimpleConnection + ConnectionSealed + Sized + Send in any way? It seems like |
It's shouldn't be semantically different to that variant, although there might have been a reason why I wrote it the other way around. If I remember correctly that might have been related to how rustc resolves traits, but I don't remember any details.
It's correct to assume that any type that implements |
I'll double-check the specific case in 99.9% chance this is just a case of "we weren't looking at |
Having dug into this and then re-read your message, both issues were at play and I had misunderstood your original point.
I believe you were trying to tip me off about the Is a doc(hidden)-but-implementable trait considered sealed?The canonical answer in Rust is "no" — sealing is a matter of ability not convention. On the other hand, I sympathize with the use case! It feels like this shouldn't be flagged because people shouldn't implement that trait themselves. If they do, it feels like any breakage should be on them. To help me figure this out, could you offer more context on why |
Diesel provides a derive which implements this trait, for that it must be reachable via a public path from a third party crate. We generally do not consider code used by the derive macro to be part of the stable API as it's common in the rust ecosystem. These traits are considered to be implementation details, as we always couple the proc macro to a specific diesel version. |
That makes sense. Thank you. I think we'll need a new set of lints so we can properly capture the nuance here. Something like an error-by-default lint on "this trait is neither sealed nor doc(hidden)-sealed, and it made a breaking change" vs a warn-by-default lint on "this trait is doc(hidden)-sealed but not sealed, and it made a breaking change so be careful even though this is maybe still okay." If we did the above, then this use case would have gotten a warning from the second lint, and no errors. (Projects can also configure lints to be allow/warn/deny using Does that sound reasonable, or would you do something differently? P.S.: I made a Discord for |
That sounds very reasonable. The other solution that I had in my mind is that if you plan to upstream this as official part of cargo you could maybe try to get a |
I brought this up at RustConf a couple of weeks ago: tool-oriented item attributes! They'd also be useful for tools like |
Which lint or lints are the issue
trait_method_added
Known issues that might be causing this
Steps to reproduce the bug with the above code
diesel-rs/diesel@f7e9819
Actual Behaviour
Expected Behaviour
I believe this is a false positive as the
Connection
trait requires thatConnectionSealed
is implemented, which in turn is private (reexport) as long as the unstablei-implement-a-third-party-backend-and-opt-into-breaking-changes
feature flag is not enabled.Verbose Lint Output
Generated System Information
Software version
cargo-semver-checks 0.35.0
Operating system
Linux 6.10.9-200.fc40.x86_64
Command-line
cargo version
Compile time information
Cargo build configuration:
[alias]
xtask = ["run", "--package", "xtask", "--"]
Build Configuration
None that are relevant
Additional Context
None
The text was updated successfully, but these errors were encountered: