-
Notifications
You must be signed in to change notification settings - Fork 2k
allow_unwrap_types #16535
Copy link
Copy link
Open
Labels
C-enhancementCategory: Enhancement of lints, like adding more cases or adding help messagesCategory: Enhancement of lints, like adding more cases or adding help messages
Metadata
Metadata
Assignees
Labels
C-enhancementCategory: Enhancement of lints, like adding more cases or adding help messagesCategory: Enhancement of lints, like adding more cases or adding help messages
Type
Fields
Give feedbackNo fields configured for issues without a type.
What it does
allow_unwrap_typesconfiguresunwrap_usedto allow any type in a given list of types to be unwrapped.Advantage
Avoids the need to
#[allow]unwrap()various types.A concrete example is to allow
unwrap()ofstd::sync::LockResultwhich is produced by locking aMutex.Drawbacks
None.
Example
Could be written as:
some_mutex .lock() .unwrap() ...;with the following in
Cargo.toml:Comparison with existing lints
When the
unwrap_usedlint is applied, the user is forced to pepper their code with#[allow(clippy::unwrap_used)]when, for example, Mutex lock results are unwrapped.Additional Context
The reasonableness of unwrapping
LockResultis discussed here: https://www.reddit.com/r/rust/comments/10f6328/is_this_a_reasonable_way_to_handle_unwrapping/.