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.

Sign up for GitHub

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

Jump to bottom

util: add track_caller to public APIs #4785

Merged
merged 2 commits into from Jun 27, 2022
Merged

util: add track_caller to public APIs #4785

merged 2 commits into from Jun 27, 2022

Commits on Jun 22, 2022

  1. util: add track_caller to public APIs 

    Functions that may panic can be annotated with `#[track_caller]` so that
in the event of a panic, the function where the user called the
panicking function is shown instead of the file and line within Tokio
source.

This change adds `#[track_caller]` to all the non-unstable public APIs in
tokio-util where the documentation describes how the function may panic
due to incorrect context or inputs.

In one place, an assert was added where the described behavior appeared
not to be implemented. The documentation for `DelayQueue::reserve`
states that the function will panic if the new capacity exceeds the
maximum number of entries the queue can contain. However, the function
didn't panic until a higher number caused by an allocation failure. This
is inconsistent with `DelayQueue::insert_at` which will panic if the
number of entries were to go over MAX_ENTRIES.

Tests are included to cover each potentially panicking function.

Refs: tokio-rs#4413
    @hds
    hds committed Jun 22, 2022
    Configuration menu
    Copy the full SHA
    4d54f3a View commit details
    Browse the repository at this point in the history

  2. fix tests on FreeBSD 32-bit (I hope) 

    Some tests were failing on FreeBSD 32-bit because the "times too far in
the future" for DelayQueue were also too far in the future for the OS.

Fixed by copying the MAX_DURATION value from where it's defined and
using it to create a duration that is just 1 more than the maximum. This
will start to break once we get close (within 2 and a bit years) of the
Epochalypse (19 Jan, 2038) - but a lot of other things are going to be
breaking on FreeBSD 32-bit by then anyway.
    @hds
    hds committed Jun 22, 2022
    Configuration menu
    Copy the full SHA
    ef13a9c View commit details
    Browse the repository at this point in the history