Open weiznich opened 2 days ago
Thanks for the report, and sorry for the inconvenience.
I have to say I've never seen a bound like the where Self: OtherTrait
before on a trait:
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 Self
will end up being ConnectionSealed
either way, and knowing that the eventual implementer of Connection
has done so successfully means that we know they also implemented ConnectionSealed
. So it seems identical to me, and yet somehow our analysis (currently!) disagrees. I'm wondering if that's a bug per se, or if I've missed some case where a where Self: Other
bound may behave differently.
Just so I make sure we get this right in our test suite, is that semantically different than writing
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.
knowing that the eventual implementer of Connection has done so successfully means that we know they also implemented ConnectionSealed.
It's correct to assume that any type that implements Connection
must implement ConnectionSealed
. The main point here is: You cannot implement ConnectionSealed
outside of diesel (at least not without the unstable feature flag or without going through a module named internal
, that is marked #[doc(hidden)]
several times), as we don't have any wild card impl for ConnectionSealed
and Connection
is implemented for all concrete types that implement ConnectionSealed
. Thinking a bit more about that, it might just be that cargo semver-check fails to see that diesel::internal
is not part of the public API?
I'll double-check the specific case in diesel
to be sure, but a priori I doubt the issue is related to the diesel::internal
API. We should be handling all those cases properly: we have a truly astonishing number of test cases checking all sorts of cursed edge cases, and nothing I saw in diesel
seems that far out of the ordinary there.
99.9% chance this is just a case of "we weren't looking at where Self: Trait
clauses in the sealing analysis" which should be an easy fix.
Having dug into this and then re-read your message, both issues were at play and I had misunderstood your original point.
where Self: Trait
as a possible means of sealing. This is fixed in https://github.com/obi1kenobi/trustfall-rustdoc-adapter/pull/497 and will be part of the next cargo-semver-checks
release.ConnectionSealed
not sealed because it's publicly accessible (behind #[doc(hidden)]
) at path:
[
ImportablePath {
path: Path {
components: [
"diesel",
"internal",
"derives",
"multiconnection",
"ConnectionSealed",
],
},
modifiers: Modifiers {
doc_hidden: true,
deprecated: false,
},
},
]
I believe you were trying to tip me off about the #[doc(hidden)]
-but-public nature of ConnectionSealed
, and I instead misinterpreted that as a concern that we might not be identifying #[doc(hidden)]
correctly. Sorry about that! We correctly identify #[doc(hidden)]
, and the issue is downstream of that: "is ConnectionSealed
actually sealed?"
The canonical answer in Rust is "no" — sealing is a matter of ability not convention. doc(hidden)
says that by convention one shouldn't use that trait, not that one cannot use it or implement it.
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 ConnectionSealed
is merely doc(hidden)
as opposed to pub-in-priv or sealed in some other way?
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
https://github.com/diesel-rs/diesel/commit/f7e9819303877b5a255143c4b32fa1e5745aaad0
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