Repository navigation
Update Rust crate tokio to v1.51.6 [SECURITY] - #1051
Open
renovate[bot] wants to merge 1 commit into
Open
renovate[bot] wants to merge 1 commit into
renovate[bot] wants to merge 1 commit into
Conversation
renovate
Bot
force-pushed
the
renovate/crate-tokio-vulnerability
branch
from
February 12, 2024 18:11
4827dba to
391b8ba
Compare
renovate
Bot
force-pushed
the
renovate/crate-tokio-vulnerability
branch
from
March 28, 2024 17:58
391b8ba to
fc584ca
Compare
renovate
Bot
force-pushed
the
renovate/crate-tokio-vulnerability
branch
from
March 29, 2024 16:22
fc584ca to
3894130
Compare
renovate
Bot
force-pushed
the
renovate/crate-tokio-vulnerability
branch
from
May 30, 2024 23:08
3894130 to
62a7eb8
Compare
renovate
Bot
force-pushed
the
renovate/crate-tokio-vulnerability
branch
from
February 22, 2025 08:40
62a7eb8 to
2e2cd81
Compare
renovate
Bot
force-pushed
the
renovate/crate-tokio-vulnerability
branch
from
April 7, 2025 18:27
2e2cd81 to
1e51dfc
Compare
renovate
Bot
force-pushed
the
renovate/crate-tokio-vulnerability
branch
from
August 10, 2025 15:53
1e51dfc to
5e0e16b
Compare
renovate
Bot
force-pushed
the
renovate/crate-tokio-vulnerability
branch
2 times, most recently
from
December 11, 2025 15:04
edc9d44 to
4b6f691
Compare
renovate
Bot
force-pushed
the
renovate/crate-tokio-vulnerability
branch
from
December 11, 2025 21:27
4b6f691 to
0d2878a
Compare
renovate
Bot
force-pushed
the
renovate/crate-tokio-vulnerability
branch
from
December 31, 2025 18:46
0d2878a to
a64eb22
Compare
renovate
Bot
force-pushed
the
renovate/crate-tokio-vulnerability
branch
from
February 2, 2026 16:16
a64eb22 to
794ddbc
Compare
renovate
Bot
force-pushed
the
renovate/crate-tokio-vulnerability
branch
from
February 12, 2026 13:33
794ddbc to
9d095ba
Compare
renovate
Bot
force-pushed
the
renovate/crate-tokio-vulnerability
branch
from
February 25, 2026 17:53
9d095ba to
84d686f
Compare
renovate
Bot
force-pushed
the
renovate/crate-tokio-vulnerability
branch
from
March 13, 2026 13:13
84d686f to
a6ca7bf
Compare
renovate
Bot
force-pushed
the
renovate/crate-tokio-vulnerability
branch
from
May 18, 2026 13:55
a6ca7bf to
3ff444f
Compare
renovate
Bot
force-pushed
the
renovate/crate-tokio-vulnerability
branch
2 times, most recently
from
June 20, 2026 06:53
47ada1a to
31b6139
Compare
renovate
Bot
force-pushed
the
renovate/crate-tokio-vulnerability
branch
from
July 21, 2026 00:33
31b6139 to
4df5b56
Compare
renovate
Bot
force-pushed
the
renovate/crate-tokio-vulnerability
branch
from
August 12, 2026 02:48
4df5b56 to
84e4ff5
Compare
renovate
Bot
force-pushed
the
renovate/crate-tokio-vulnerability
branch
from
September 25, 2026 00:20
84e4ff5 to
a554e7f
Compare
renovate
Bot
force-pushed
the
renovate/crate-tokio-vulnerability
branch
from
October 13, 2026 13:50
a554e7f to
65dc801
Compare
renovate
Bot
force-pushed
the
renovate/crate-tokio-vulnerability
branch
from
October 20, 2026 15:35
65dc801 to
6555c27
Compare
Signed-off-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
renovate
Bot
force-pushed
the
renovate/crate-tokio-vulnerability
branch
from
October 23, 2026 18:17
6555c27 to
321a080
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Note
This PR body was truncated due to platform limits.
This PR contains the following updates:
1.13.0→1.51.61.13.0→1.51.6Race Condition in tokio
CVE-2021-45710 / GHSA-fg7r-2g4j-5cgr
More information
Details
If a tokio::sync::oneshot channel is closed (via the oneshot::Receiver::close method), a data race may occur if the oneshot::Sender::send method is called while the corresponding oneshot::Receiver is awaited or calling try_recv.
When these methods are called concurrently on a closed channel, the two halves of the channel can concurrently access a shared memory location, resulting in a data race. This has been observed to cause memory corruption.
Note that the race only occurs when both halves of the channel are used after the Receiver half has called close. Code where close is not used, or where the Receiver is not awaited and try_recv is not called after calling close, is not affected.
Severity
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Tokio reject_remote_clients configuration may get dropped when creating a Windows named pipe
CVE-2023-22466 / GHSA-7rrj-xr53-82p7
More information
Details
Impact
When configuring a Windows named pipe server, setting
pipe_modewill resetreject_remote_clientstofalse. If the application has previously configuredreject_remote_clientstotrue, this effectively undoes the configuration. This also applies ifreject_remote_clientsis not explicitly set as this is the default configuration and is cleared by callingpipe_mode.Remote clients may only access the named pipe if the named pipe's associated path is accessible via a publically shared folder (SMB).
Patches
The following versions have been patched:
The fix will also be present in all releases starting from version 1.24.0.
Named pipes were introduced to Tokio in version 1.7.0, so releases older than 1.7.0 are not affected.
Workarounds
Ensure that
pipe_modeis set first after initializing aServerOptions. For example:References
https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createnamedpipea#pipe_reject_remote_clients
Severity
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:LReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
tokio::io::ReadHalf<T>::unsplitis UnsoundGHSA-4q83-7cq4-p6wg
More information
Details
tokio::io::ReadHalf<T>::unsplitcan violate thePincontractThe soundness issue is described in the tokio/issues#5372
Specific set of conditions needed to trigger an issue (a !Unpin type in ReadHalf)
is unusual, combined with the difficulty of making any arbitrary use-after-free
exploitable in Rust without doing a lot of careful alignment of data types in
the surrounding code.
The
tokiofeatureio-utilis also required to be enabled to trigger thissoundness issue.
Thanks to zachs18 reporting the issue to Tokio team responsibly and taiki-e
and carllerche appropriately responding and fixing the soundness bug.
Tokio before 0.2.0 used
futures0.1 that did not havePin, so it is notaffected by this issue.
Severity
Low
References
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Tokio broadcast channel calls clone in parallel, but does not require
SyncGHSA-rr8g-9fpq-6wmg
More information
Details
The broadcast channel internally calls
cloneon the stored value when receiving it, and only requiresT:Send. This means that using the broadcast channel with values that areSendbut notSynccan trigger unsoundness if thecloneimplementation makes use of the value being!Sync.Thank you to Austin Bonander for finding and reporting this issue.
Severity
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:UReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Race Condition in tokio
CVE-2021-45710 / GHSA-fg7r-2g4j-5cgr / RUSTSEC-2021-0124
More information
Details
If a tokio::sync::oneshot channel is closed (via the oneshot::Receiver::close method), a data race may occur if the oneshot::Sender::send method is called while the corresponding oneshot::Receiver is awaited or calling try_recv.
When these methods are called concurrently on a closed channel, the two halves of the channel can concurrently access a shared memory location, resulting in a data race. This has been observed to cause memory corruption.
Note that the race only occurs when both halves of the channel are used after the Receiver half has called close. Code where close is not used, or where the Receiver is not awaited and try_recv is not called after calling close, is not affected.
Severity
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Data race when sending and receiving after closing a
oneshotchannelCVE-2021-45710 / GHSA-fg7r-2g4j-5cgr / RUSTSEC-2021-0124
More information
Details
If a
tokio::sync::oneshotchannel is closed (via theoneshot::Receiver::closemethod), a data race may occur if theoneshot::Sender::sendmethod is called while the correspondingoneshot::Receiverisawaited or callingtry_recv.When these methods are called concurrently on a closed channel, the two halves
of the channel can concurrently access a shared memory location, resulting in a
data race. This has been observed to cause memory corruption.
Note that the race only occurs when both halves of the channel are used
after the
Receiverhalf has calledclose. Code wherecloseis not used, or where theReceiveris notawaited andtry_recvis not called after callingclose,is not affected.
See tokio#4225 for more details.
Severity
Unknown
References
This data is provided by OSV and the Rust Advisory Database (CC0 1.0).
Tokio reject_remote_clients configuration may get dropped when creating a Windows named pipe
CVE-2023-22466 / GHSA-7rrj-xr53-82p7 / RUSTSEC-2023-0001
More information
Details
Impact
When configuring a Windows named pipe server, setting
pipe_modewill resetreject_remote_clientstofalse. If the application has previously configuredreject_remote_clientstotrue, this effectively undoes the configuration. This also applies ifreject_remote_clientsis not explicitly set as this is the default configuration and is cleared by callingpipe_mode.Remote clients may only access the named pipe if the named pipe's associated path is accessible via a publically shared folder (SMB).
Patches
The following versions have been patched:
The fix will also be present in all releases starting from version 1.24.0.
Named pipes were introduced to Tokio in version 1.7.0, so releases older than 1.7.0 are not affected.
Workarounds
Ensure that
pipe_modeis set first after initializing aServerOptions. For example:References
https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createnamedpipea#pipe_reject_remote_clients
Severity
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:LReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
reject_remote_clients Configuration corruption
CVE-2023-22466 / GHSA-7rrj-xr53-82p7 / RUSTSEC-2023-0001
More information
Details
On Windows, configuring a named pipe server with pipe_mode will force ServerOptions::reject_remote_clients as
false.This drops any intended explicit configuration for the reject_remote_clients that may have been set as
truepreviously.The default setting of reject_remote_clients is normally
truemeaning the default is also overridden asfalse.Workarounds
Ensure that pipe_mode is set first after initializing a ServerOptions. For example:
Severity
Unknown
References
This data is provided by OSV and the Rust Advisory Database (CC0 1.0).
tokio::io::ReadHalf<T>::unsplitis UnsoundGHSA-4q83-7cq4-p6wg / RUSTSEC-2023-0005
More information
Details
tokio::io::ReadHalf<T>::unsplitcan violate thePincontractThe soundness issue is described in the tokio/issues#5372
Specific set of conditions needed to trigger an issue (a !Unpin type in ReadHalf)
is unusual, combined with the difficulty of making any arbitrary use-after-free
exploitable in Rust without doing a lot of careful alignment of data types in
the surrounding code.
The
tokiofeatureio-utilis also required to be enabled to trigger thissoundness issue.
Thanks to zachs18 reporting the issue to Tokio team responsibly and taiki-e
and carllerche appropriately responding and fixing the soundness bug.
Tokio before 0.2.0 used
futures0.1 that did not havePin, so it is notaffected by this issue.
Severity
Low
References
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
tokio::io::ReadHalf<T>::unsplitis UnsoundGHSA-4q83-7cq4-p6wg / RUSTSEC-2023-0005
More information
Details
tokio::io::ReadHalf<T>::unsplitcan violate thePincontractThe soundness issue is described in the tokio/issues#5372
Specific set of conditions needed to trigger an issue (a !Unpin type in ReadHalf)
is unusual, combined with the difficulty of making any arbitrary use-after-free
exploitable in Rust without doing a lot of careful alignment of data types in
the surrounding code.
The
tokiofeatureio-utilis also required to be enabled to trigger thissoundness issue.
Thanks to zachs18 reporting the issue to Tokio team responsibly and taiki-e
and carllerche appropriately responding and fixing the soundness bug.
Tokio before 0.2.0 used
futures0.1 that did not havePin, so it is notaffected by this issue.
Severity
Unknown
References
This data is provided by OSV and the Rust Advisory Database (CC0 1.0).
Tokio broadcast channel calls clone in parallel, but does not require
SyncGHSA-rr8g-9fpq-6wmg / RUSTSEC-2025-0023
More information
Details
The broadcast channel internally calls
cloneon the stored value when receiving it, and only requiresT:Send. This means that using the broadcast channel with values that areSendbut notSynccan trigger unsoundness if thecloneimplementation makes use of the value being!Sync.Thank you to Austin Bonander for finding and reporting this issue.
Severity
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:UReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
Broadcast channel calls clone in parallel, but does not require
SyncGHSA-rr8g-9fpq-6wmg / RUSTSEC-2025-0023
More information
Details
The broadcast channel internally calls
cloneon the stored value whenreceiving it, and only requires
T:Send. This means that using the broadcastchannel with values that are
Sendbut notSynccan trigger unsoundness ifthe
cloneimplementation makes use of the value being!Sync.Thank you to Austin Bonander for finding and reporting this issue.
Severity
Unknown
References
This data is provided by OSV and the Rust Advisory Database (CC0 1.0).
AsyncFd::newand related constructors violate I/O safetyRUSTSEC-2026-0386
More information
Details
tokio::io::unix::AsyncFdprovides safe constructors (new,with_interest,try_new, andtry_with_interest) that accept anyT: AsRawFdrather than requiring proof of ownership or validity of the file descriptor. BecauseRawFdimplementsAsRawFd, safe code can construct anAsyncFdfrom an arbitrary or closed file descriptor, or close/replace the underlying file descriptor while theAsyncFdis still alive.This violates I/O safety in two ways:
AsyncFd<T>implementsAsFdfor allT: AsRawFdby callingBorrowedFd::borrow_raw(self.as_raw_fd()), allowing safe code to obtain an arbitraryBorrowedFd<'_>without owning the file descriptor.epoll/kqueueuser data for registered file descriptors. If the underlying file descriptor is duplicated and then closed while anAsyncFdis alive, and the OS reuses that file descriptor number for a another IO resource on the same runtime, dropping the firstAsyncFdderegisters the reused file descriptor number and frees the first while the original file description remains registered inepoll, leading to a use-after-free when a readiness event fires.Starting in Tokio 1.51.6, 1.53.3, and 1.54.0,
AsyncFd::new,AsyncFd::with_interest,AsyncFd::try_new, andAsyncFd::try_with_interestare deprecated in favor of theunsafeconstructorsAsyncFd::registerandAsyncFd::register_with_interest. Callers must ensure that the file descriptor remains valid, open, and unchanged for the lifetime of theAsyncFd.Severity
Unknown
References
This data is provided by OSV and the Rust Advisory Database (CC0 1.0).
Release Notes
tokio-rs/tokio (tokio)
v1.51.6: Tokio v1.51.6Compare Source
1.51.6 (October 13th, 2026)
Added
AsyncFd::registerandAsyncFd::register_with_interest(#8587)Changed
AsyncFd::{new, with_interest, try_new, try_with_interest}(#8587)Fixed
DuplexStreamwakers outside the lock (#8618)unreachable_codeinjoin!andtry_join!forInfallible(#8518)current_thread(#8595)v1.51.5: Tokio v1.51.5Compare Source
1.51.5 (October 3rd, 2026)
Fixed
AsyncFdregistration list on deregister" (#8540)Permitbefore sending value (#8560)MAX_PERMITSinSemaphore::acquire(#8548)Sender::closedoutside mutex (#8558)JoinSet(#8554)clear_entry(#8552)Fixed (unstable)
current_threadtask dumps from other runtimes (#8544)io_uringcontext if a completion waker panics (#8566)v1.51.4: Tokio v1.51.4Compare Source
1.51.4 (July 16th, 2026)
Fixed
before_parkschedules work (#8222)v1.51.3: Tokio v1.51.3Compare Source
1.51.3 (May 8th, 2026)
Fixed
len()(#8062)OwnedPermit::release()method (#8075)RwLockhasmax_readers != 0(#8076)Emptyfromtry_recv()when mpsc is closed with outstanding permits (#8074)v1.51.2: Tokio v1.51.1Compare Source
1.51.2 (May 4th, 2026)
This release reverts the LIFO slot stealing change introduced in 1.51.0 (#7431), due to its performance impact. (#8100)
v1.51.1: Tokio v1.51.1Compare Source
1.51.1 (April 8th, 2026)
Fixed
SO_ERRORonrecvfor UDP sockets on Linux (#8001)Fixed (unstable)
worker_local_schedule_counttest (#8008)v1.51.0: Tokio v1.51.0Compare Source
1.51.0 (April 3rd, 2026)
Added
get_peer_credon Hurd (#7989)tokio::runtime::worker_index()(#7921)LocalRuntime(#7557)Changed
Fixed
notify_waiterspriority inNotify(#7996)Chan::recv_manywhen called with non-empty vector on closed channel (#7991)v1.50.0: Tokio v1.50.0Compare Source
1.50.0 (Mar 3rd, 2026)
Added
TcpStream::set_zero_linger(#7837)is_rt_shutdown_err(#7771)Changed
memchrreturns in-bounds pointer (#7792)write_buf(#7871)event_intervalis set to 0 (#7838)SetConsoleCtrlHandler(#7833)Registry(#7885)Fixed
AsyncFdregistration list on deregister (#7773)usedeclarations intokio::select!(#7929)GET_BUF_SIZEconstant fortarget_os = "android"(#7889)current_threadifbefore_parkdefers waker (#7835)block_in_place(#7879)num_idle_threadson shutdown (#7910, #7918, #7922)Unstable
Documented
AsyncWriteExt::shutdown()(#7908)AsyncWritedocumentation (#7875)Runtime::spawn(#7803)event_intervaldoc (#7932)recvreturnsNoneonce closed and no more messages (#7920)spawn_blockingvs dedicated threads (#7923)JoinHandlecompletion (#7825)None(#7869)Builder::spawn_local(#7828)v1.49.0: Tokio v1.49.0Compare Source
1.49.0 (January 3rd, 2026)
Added
TCLASSoption on IPv6 (#7781)runtime::id::Id(#7125)ExtendforJoinSet(#7195)LocalSet::id()(#7776)Changed
{TcpStream,TcpSocket}::set_linger(#7752)Fixed
join!andtry_join!(#7766)TryRecvError::DisconnectedfromReceiver::try_recvafterReceiver::close(#7686)Debugimplementation (#7720)Unstable
EINTRinfs::writefor io-uring (#7786)tokio::fs::read(#7696)EPERM(#7724)Documented
bounded.rsandpark.rs(#7817)SyncIoBridgecross-references tocopyandcopy_buf(#7798)AsyncWritedoes not inherit fromstd::io::Write(#7705)num_alive_tasksis not strongly consistent (#7614)TcpStream::peek(#7305)unix::OwnedWriteHalf(#7742)TcpSocketdocs (#7738)LocalRuntimeinnew_current_threaddocs (#7820)mpsc::Sender::try_senddocs (#7721)oneshot::Receiver(#7780)errorsof mpsc (#7722)spawn_localusage on local runtime (#7689)v1.48.0: Tokio v1.48.0Compare Source
1.48.0 (October 14th, 2025)
The MSRV is increased to 1.71.
Added
File::max_buf_size(#7594)ChainofAsyncReadExt::chain(#7599)SocketAddr::as_abstract_name(#7491)TcpStream::quickackandTcpStream::set_quickack(#7490)AsRef<Self>forTcpStreamandUnixStream(#7573)LocalKey::try_get(#7666)Ordfortask::Id(#7530)Changed
max_buf_sizewhen cloning aFile(#7593)clippy::unwrap_in_resultin#[tokio::main](#7651)PollEventednoise from Debug formats (#7675)Command::spawn_withto useFnOnce(#7511)SetOnce(#7554)UnsafeCell::get_mutinMutex::get_mutandRwLock::get_mut(#7569)Timeout<T>::poll(#7535)Fixed
join!andtry_join!(#7638)wake_by_ref()even if already woken (#7622)broadcast::Senderinbroadcast::Sender::new()(#7629)RwLock::try_*methods (#7587)Unstable
--cfgflags fortaskdumpandio_uring(#7655, #7621)io_uringinfs::write(#7567)io_uringwithFile::open()(#7617)io_uringwithOpenOptions(#7321)localruntime flavor (#7375, #7597)Documented
AsyncRead::poll_read(#7580)AsyncFdreadiness guards (#7583)UCred::pid()on Cygwin (#7611)set_reuseport()andreuseport()(#7628)SO_REUSEADDRis only set on Unix (#7533)Handle::block_on(#7665)Builder::global_queue_interval()(#7605)tokio::sync::watch::Receiver(#7584)SetOnce::wait(#7506)parking_lotfeature flag (#7663)UnboundedSender::send(#7661)sync::watch(#7601)spawn_localmethods (#7669)poll_proceed(#7586)v1.47.5: Tokio v1.47.5Compare Source
1.47.5 (May 7th, 2026)
Fixed
len()(#8062)OwnedPermit::release()method (#8075)RwLockhasmax_readers != 0(#8076)Emptyfromtry_recv()when mpsc is closed with outstanding permits (#8074)v1.47.4: Tokio v1.47.4Compare Source
1.47.4 (April 2nd, 2026)
Fixed
Chan::recv_manywhen called with non-empty vector on closed channel (#7991)v1.47.3Compare Source
v1.47.2Compare Source
v1.47.1: Tokio v1.47.1Compare Source
1.47.1 (August 1st, 2025)
Fixed
asyncio.EventinSetOncedocs (#7485)v1.47.0: Tokio v1.47.0Compare Source
1.47.0 (July 25th, 2025)
This release adds
poll_proceedandcooperativeto thecoopmodule forcooperative scheduling, adds
SetOnceto thesyncmodule which providessimilar functionality to [
std::sync::OnceLock], and adds a new methodsync::Notify::notified_owned()which returns anOwnedNotifiedwithouta lifetime parameter.
Added
cooperativeandpoll_proceed(#7405)SetOnce(#7418)sync::Notify::notified_owned()(#7465)Changed
AtomicWaker::wakeperformance (#7450)Documented
Readiness<'_>(#7415)v1.46.1: Tokio v1.46.1Compare Source
1.46.1 (July 4th, 2025)
This release fixes incorrect spawn locations in runtime task hooks for tasks spawned using
tokio::spawnrather thanRuntime::spawn. This issue only effected the spawn location inTaskMeta::spawned_at, and did not effect task locations in Tracing events.Unstable
TaskMeta::spawn_locationtracking where a task was spawned (#7440)v1.46.0: Tokio v1.46.0Compare Source
1.46.0 (July 2nd, 2025)
Fixed
TcpStream::shutdownincorrectly returning an error on macOS (#7290)Added
mpsc::OwnedPermit::{same_channel, same_channel_as_sender}methods ([#7389])biasedoption forjoin!andtry_join!, similar toselect!(#7307)pope::OpenOptions::read_writeon Android ([#7426])Cloneimplementation fornet::unix::SocketAddr([#7422])Changed
queue::Local<T>(#7340)LocalSet::{poll,drop}([#7372])Unstable
TaskMeta::spawn_locationtracking where a task was spawned ([#7417])LocalOptionsparameter toruntime::Builder::build_local([#7346])Documented
start_seekis not used ([#7366])AsyncWriteExt::flush([#7364])recv_buffer_sizemethod (#7336)RawFdinTcpSocketdocs ([#7416])AsRawFddoc link to current Rust stdlib location ([#7429])on_*_task_pollis unstable (#7311)time::advance([#7394])Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.
This PR was generated by Mend Renovate. View the repository job log.