Add #[track_caller]
for better panic messages for fallible locks using lock_api
.
#456
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I would like to write a
RawMutex
implementation that behaves like a mutable-borrow-onlyRefCell
. This is fairly trivial, but the main difference is thatRefCell
leverages#[track_caller]
andstd::panic::Location::caller
to provide great panic messages whendebug_assertions
are enabled, indicating where the prior borrow occurred when panicking. I'd like to replicate that, but the issue is thatlock_api::Mutex
'slock
function doesn't have the#[track_caller]
attribute which results in error messages saying "could not borrow when previously borrows here: [in the lock_api::Mutex::lock function]".In general, if a RawMutex's
lock
implementation ever fails AND the writer of theRawMutex
impl marked thelock
function with#[track_caller]
, I think it's much more helpful for any panic to indicate where the user of thelock_api::Mutex
calledlock
rather than wherelock_api::Mutex
calledlock_api::RawMutex::lock
. The latter is useless information, the former is very useful for... well, making an unsynchronized RefCell-like lock (the RawMutex is !Sync and the Guard is !Send).This PR marks some of the
lock
functions inlock_api
with#[track_caller]
where they might reasonably panic for similar reasons.