While switching from write to write_arc in some wrapper I'm making, I expected the return to change from parking_lot::RwLockWriteGuard to parking_lot::ArcRwLockWriteGuard, so:
But the ArcRwLockWriteGuard isn't present in the root of the crate, even with the arc_lock feature;
141 | pub fn write_arc(&self) -> parking_lot::ArcRwLockWriteGuard<parking_lot::RawRwLock, WorldState> {
| ^^^^^^^^^^^^^^^^^^^ help: a type alias with a similar name exists: `RwLockWriteGuard`
|
::: /home/ivor/.cargo/registry/src/index.crates.io-6f17d22bba15001f/parking_lot-0.12.2/src/rwlock.rs:103:1
|
103 | pub type RwLockWriteGuard<'a, T> = lock_api::RwLockWriteGuard<'a, RawRwLock, T>;
| -------------------------------- similarly named type alias `RwLockWriteGuard` defined here
The actual return type is lock_api::ArcRwLockWriteGuard, from the lock_api crate instead of the parking_lot crate, the error isn't particularly helpful as it points to the wrong lock guard type.
Interestingly enough, reproducing this on the playground, does result in two suggestions, one of which is the good one. The good suggestion only happens if lock_api is listed as a dependency in the targets' Cargo.toml file, but if there's a dependency on parking_lot, and that re-exports lock_api (#150), I expect most users will not add a direct dependency on lock_api, effectively hiding this useful suggestion.
In short; I was confused by this behaviour, the docs don't show clearly that ArcRwLockWriteGuard is from the lock_api crate and I just assumed the new structs would be exported after enabling the feature. I learned to check the return types carefully, but thought I'd still file a PR for it as it can be fixed easily to prevent others from running into this. Feel free to close the PR if it is deemed undesirable to re-export these types at the root of the parking_lot crate.
While switching from
write
towrite_arc
in some wrapper I'm making, I expected the return to change fromparking_lot::RwLockWriteGuard
toparking_lot::ArcRwLockWriteGuard
, so:But the
ArcRwLockWriteGuard
isn't present in the root of the crate, even with thearc_lock
feature;The actual return type is
lock_api::ArcRwLockWriteGuard
, from thelock_api
crate instead of theparking_lot
crate, the error isn't particularly helpful as it points to the wrong lock guard type.Interestingly enough, reproducing this on the playground, does result in two suggestions, one of which is the good one. The good suggestion only happens if
lock_api
is listed as a dependency in the targets'Cargo.toml
file, but if there's a dependency onparking_lot
, and that re-exportslock_api
(#150), I expect most users will not add a direct dependency onlock_api
, effectively hiding this useful suggestion.In short; I was confused by this behaviour, the docs don't show clearly that
ArcRwLockWriteGuard
is from thelock_api
crate and I just assumed the new structs would be exported after enabling the feature. I learned to check the return types carefully, but thought I'd still file a PR for it as it can be fixed easily to prevent others from running into this. Feel free to close the PR if it is deemed undesirable to re-export these types at the root of theparking_lot
crate.