Clarify that LocalKey::try_with may return AccessError#158760
Merged
rust-bors[bot] merged 1 commit intoJul 8, 2026
Conversation
The docs stated that try_with will return an AccessError when the key has been destroyed. This is not guaranteed: on some platforms, TLS slots can be re-initialized during destruction, so the destroyed state cannot always be observed. Change 'will' to 'may' to accurately reflect the best-effort nature of the check.
rustbot
added
S-waiting-on-review
Collaborator
|
Thanks for the pull request, and welcome! The Rust Project is excited to review your changes, and you should hear from @aapoalas (or someone else) some time within the next two weeks. Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (
Why was this reviewer chosen?The reviewer was selected based on:
|
rustbot
added
the
A-docs
Contributor
rust-bors
Bot
added
S-waiting-on-bors
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Jul 7, 2026
…-return, r=aapoalas Clarify that `LocalKey::try_with` may return `AccessError` The docs for `LocalKey::try_with` state that the function *will* return an `AccessError` when the key has been destroyed. That's not actually guaranteed: - `LocalKey::with` uses `try_with` internally and its docs explicitly acknowledge that it does not always panic when the destructor has run. If `try_with` really did detect every destroyed thread-local, `with` could always panic. - The top-level `LocalKey` docs already note: "On all platforms it's possible for TLS to re-initialize other TLS slots during destruction." Change *will* to *may* to accurately reflect the best-effort nature of the destroyed-key check. Closes rust-lang#157889 @rustbot label +A-docs
JonathanBrouwer
added a commit
to JonathanBrouwer/rust
that referenced
this pull request
Jul 7, 2026
…-return, r=aapoalas Clarify that `LocalKey::try_with` may return `AccessError` The docs for `LocalKey::try_with` state that the function *will* return an `AccessError` when the key has been destroyed. That's not actually guaranteed: - `LocalKey::with` uses `try_with` internally and its docs explicitly acknowledge that it does not always panic when the destructor has run. If `try_with` really did detect every destroyed thread-local, `with` could always panic. - The top-level `LocalKey` docs already note: "On all platforms it's possible for TLS to re-initialize other TLS slots during destruction." Change *will* to *may* to accurately reflect the best-effort nature of the destroyed-key check. Closes rust-lang#157889 @rustbot label +A-docs
rust-bors Bot
pushed a commit
that referenced
this pull request
Jul 7, 2026
…uwer Rollup of 18 pull requests Successful merges: - #157385 (Enable Enzyme on x86_64-apple) - #157561 (rustdoc: do not include extra stuff in span) - #158179 (std: unconditionally use `preadv`/`pwritev` on AArch64 macOS) - #158617 (allow mGCA const arguments to fall back to anon consts) - #158621 (disallow `extern "custom"` on wasm and spirv targets) - #158690 (delegation: support mapping of all arguments with `Self` type) - #158696 (Rename some `body_id` to `body_def_id`) - #158697 (Fixes for QNX SDP 8) - #158760 (Clarify that `LocalKey::try_with` may return `AccessError`) - #157801 (Rewrite safety requirements for `Allocator` impls) - #158333 (Fix typetree generation for differentiated functions) - #158646 (powerpc64le_unknown_freebsd.rs: link with -lgcc) - #158701 ( diagnostics: suggest type annotation for closure params on HRTB FnOnce mismatch) - #158791 (Avoid unused braces lint for macro generated arguments) - #158802 (Use `ci-mirrors` in `armhf-gnu` for {busybox, ubuntu rootfs} artifacts) - #158841 (Avoid final override ICE for RPITIT associated types) - #158889 (tests: catch up with LLVM returning f128 on the stack) - #158905 (delegation: add constraints to new generic args)
rust-bors Bot
pushed a commit
that referenced
this pull request
Jul 7, 2026
…uwer Rollup of 19 pull requests Successful merges: - #156016 (view-types: store view types in the AST) - #157385 (Enable Enzyme on x86_64-apple) - #158179 (std: unconditionally use `preadv`/`pwritev` on AArch64 macOS) - #158621 (disallow `extern "custom"` on wasm and spirv targets) - #158690 (delegation: support mapping of all arguments with `Self` type) - #158696 (Rename some `body_id` to `body_def_id`) - #158697 (Fixes for QNX SDP 8) - #158760 (Clarify that `LocalKey::try_with` may return `AccessError`) - #157801 (Rewrite safety requirements for `Allocator` impls) - #158085 (rustdoc: Fix sidebar heading order) - #158333 (Fix typetree generation for differentiated functions) - #158646 (powerpc64le_unknown_freebsd.rs: link with -lgcc) - #158701 ( diagnostics: suggest type annotation for closure params on HRTB FnOnce mismatch) - #158791 (Avoid unused braces lint for macro generated arguments) - #158802 (Use `ci-mirrors` in `armhf-gnu` for {busybox, ubuntu rootfs} artifacts) - #158841 (Avoid final override ICE for RPITIT associated types) - #158889 (tests: catch up with LLVM returning f128 on the stack) - #158905 (delegation: add constraints to new generic args) - #158922 (tests: clean up over-constraint on LLVM feature count) Failed merges: - #158617 (allow mGCA const arguments to fall back to anon consts)
rust-timer
added a commit
that referenced
this pull request
Jul 8, 2026
Rollup merge of #158760 - kpeis695:fix/localkey-try-with-may-return, r=aapoalas Clarify that `LocalKey::try_with` may return `AccessError` The docs for `LocalKey::try_with` state that the function *will* return an `AccessError` when the key has been destroyed. That's not actually guaranteed: - `LocalKey::with` uses `try_with` internally and its docs explicitly acknowledge that it does not always panic when the destructor has run. If `try_with` really did detect every destroyed thread-local, `with` could always panic. - The top-level `LocalKey` docs already note: "On all platforms it's possible for TLS to re-initialize other TLS slots during destruction." Change *will* to *may* to accurately reflect the best-effort nature of the destroyed-key check. Closes #157889 @rustbot label +A-docs
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
3 participants
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.
The docs for
LocalKey::try_withstate that the function will return anAccessErrorwhen the key has been destroyed. That's not actually guaranteed:LocalKey::withusestry_withinternally and its docs explicitly acknowledge that it does not always panic when the destructor has run. Iftry_withreally did detect every destroyed thread-local,withcould always panic.LocalKeydocs already note: "On all platforms it's possible for TLS to re-initialize other TLS slots during destruction."Change will to may to accurately reflect the best-effort nature of the destroyed-key check.
Closes #157889
@rustbot label +A-docs