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

Export types provided by arc_lock feature. #442

Merged

Conversation

iwanders
Copy link
Contributor

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:

pub fn write(&self) -> parking_lot::RwLockWriteGuard<'_, WorldState> { }
// to 
pub fn write_arc(&self) -> parking_lot::ArcRwLockWriteGuard<parking_lot::RawRwLock, WorldState> { }

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.

This adds conditional re-exports of the Arc-related types from the lock_api crate.
@Amanieu Amanieu merged commit f7efcae into Amanieu:master May 24, 2024
37 checks passed
@Amanieu
Copy link
Owner

Amanieu commented May 24, 2024

Published in 0.12.3

@iwanders
Copy link
Contributor Author

Thanks @Amanieu 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants