Make get_unchecked(_mut) docs consistent#9
Closed
yilin0518 wants to merge 868 commits into
Closed
Conversation
…nathanBrouwer Rollup of 15 pull requests Successful merges: - rust-lang#153697 (Add arg splat experiment initial tuple impl) - rust-lang#158360 (Various borrowck cleanups and param_env/opaque_types_defined_by query simplifications for typeck children) - rust-lang#158438 (Use rigidness marker in fast_reject) - rust-lang#157127 (cg_LLVM: Stop needing an alloca for volatile loads) - rust-lang#158376 (Suggest `>=` for `=>` typo in closure and call argument positions) - rust-lang#158185 (perf: Make stable_crate_ids reads lock-free after crate loading) - rust-lang#158244 (Attribute docs `deprecated` , `warn`, `allow`, `cfg`, `deny`, and `forbid` ) - rust-lang#158355 (Fixup the refactoring errors in rust-lang#156246) - rust-lang#158361 (Move `check_ffi_pure` into the attribute parser) - rust-lang#158382 (Add safety section for SliceIndex::get_unchecked(mut)) - rust-lang#158399 (std: truncate thread names on NetBSD) - rust-lang#158418 (Eliminate double length check in `Vec::into_array`) - rust-lang#158430 (Guard clone suggestion against empty obligation errors) - rust-lang#158446 (Update Enzyme submodule) - rust-lang#158448 (Cleanup `NumBuffer` comment and replace `ilog(10)` with `ilog10()`)
To explain some non-obvious things that took me some time to work out.
`EarlyLintPassObjects` is an old name.
As `*CombinedLateLintModPass`, because that matches things like `late_lint_mod`.
We generally write `lint_pass`/`LintPass`. This commit renames some things that only use `pass`/`Pass`. And also some `s/module/mod` changes, too.
There are `register_*_lint_pass` methods, might as well go through them.
This updates the rust-version file to 1676160.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@1676160 Filtered ref: rust-lang/miri@170488c Upstream diff: rust-lang/rust@40557f6...1676160 This merge was created using https://github.com/rust-lang/josh-sync.
Automatic Rustup
This check is already handled in `rustc_trait_selection::traits::fulfill::FulfillProcessor::process_obligation`.
Update cargo submodules 6 commits in a595d0da21f228b7fdae64d3d5c0e527ea66bb59..a335d47ff8036918d3d548dabd513dc0444096a9 2026-06-20 13:42:59 +0000 to 2026-06-26 20:39:41 +0000 - fix(diag): Remove sometimes-invalid removal suggestions (rust-lang/cargo#17139) - feat: Add `-Zhint-msrv` flag (rust-lang/cargo#17106) - fix: LockManager use OS-aware flock shim (rust-lang/cargo#17128) - fix: flaky test: sparse_blocking_count (rust-lang/cargo#17130) - Add Solaris fcntl file locking (rust-lang/cargo#17110) - fix(test): skip dwp uplift test without packed debuginfo (rust-lang/cargo#17127) r? ghost
Use `TargetFeatureParser` to reject `#[target_feature]` on functions marked as lang items (via `#[lang = "..."]` or `#[panic_handler]`), replacing `check_target_feature` in `rustc_passes`.
This is a generalization of PR 92940: that PR handled cases like `impl Foreign for Box<Local>`, but was missing handling for a few other closely related cases. My particular interest was with showing `impl From<Box<Utf8Path>> for Box<Path>` in camino's documentation. But I ended up handling a bunch of related cases along the way. I'm new to rustdoc so please let me know if I got anything wrong :) took a bit to fully understand how this worked.
…atedConst-to-aliasconst, r=BoxyUwU,khyperia Rename UnevaluatedConst to AliasConst refer: rust-lang/project-const-generics#115 r? @khyperia I only renamed the type system version to `AliasConst`/`AliasConstKind`. I did not rename MIR’s `UnevaluatedConst`, it currently holds direct def_id instead of kind variant we have in type-system. I also left `rustc_public`’s `UnevaluatedConst` unchanged.
Removing the readable readiness after a short read even when the read end is closed would mean that applications which strictly rely on the readable readiness (e.g. tokio) would no longer read zero (indicating EOF) on the closed socket. This is problematic as those applications could block indefinitely waiting for a readable event on the socket.
…rochenkov Remove unnecessary `Clone` derives on resolver types The starting point of this commit is that `ModuleData`, `ImportData`, and `DeclData` are all interned, and don't need to be `Clone`. Then there are various types nestled within these types that also don't need to be `Clone`. r? @petrochenkov
…, r=Nadrieril Add missing `needs_drop` check to `DroplessArena`. Three of the four public allocation functions in `DroplessArena` check that the allocated type doesn't implement `Drop`: `alloc`, `alloc_slice`, `alloc_from_iter`. This commit adds the missing check to `try_alloc_from_iter`. It also moves and reorders some lines in `alloc_from_iter` for consistency with the other methods. r? @Nadrieril
…arfonthey Document `strip_circumfix` behavior on overlapping prefix and suffix. Fixes rust-lang#158388, as per T-libs-api decision there.
…nathanBrouwer Rollup of 8 pull requests Successful merges: - rust-lang#158294 (Use .drectve for MSVC DLL exports) - rust-lang#156716 (tests: fix: parallel frontend test failures: different alloc ids) - rust-lang#158397 (delegation: support simplest output `Self` mapping) - rust-lang#158613 (Fix getrandom fallback test on platforms with `panic=abort`) - rust-lang#158620 (Remove skip_norm_w/i/p().def_id with a helper) - rust-lang#158633 (Remove unnecessary `Clone` derives on resolver types) - rust-lang#158634 (Add missing `needs_drop` check to `DroplessArena`.) - rust-lang#158647 (Document `strip_circumfix` behavior on overlapping prefix and suffix.)
We don't need any features from `twox-hash`, and in particular this removes the last use of `rand v0.8` in our lock file.
## Fix struct links There are several structs (`ExitStatus` and `ExitStatusError`) that could be linked, but aren't. Fixed. All links show their struct now instead of previously some showed `process::ExitStatus` when rendered. ## Add `wait` links The docs distinguish `wait` as code, but do not link to **what** wait they're referring to. As this is Unix extension documentation, adding a link to the POSIX standard for `wait`. Showing a construction of an `ExitStatus` for both a signal and an exit code helps to highlight and internalize what **wait status, not an exit status** means. ## Example for `from_raw` Current documentation calls out "The value should be a **wait status, not an exit status**." but it's unclear what exactly that means without a reference or an example. I added a doctest that shows you need to shift by 8 to get the desired result and annotated it with information about how that's derived based on the linked `wait` documentation. ## Example to `ExitStatus::signal` Called out that a signaled process does not also produce an exit code. Added an example. Called out that just because a process reports that it was not terminated via a signal doesn't mean it never got one (it could be handled). Also added a note correlating shell behavior to exit codes: GNU Bash manual: https://web.archive.org/web/20260625050034/https://www.gnu.org/software/bash/manual/bash.html#Exit-Status-1 > [...] a fatal signal whose number is N, Bash uses the value 128+N as the exit status. FreeBSD bash(1) man page: https://man.freebsd.org/bash/1 > The return value [...] 128+n if the command is terminated by signal n. ## Panic scope on `from_raw` This change is based on preference/experience: When I originally read this documentation, it was because I clicked through `Output` -> `ExitStatus`. While the text "Creates a new `ExitStatus` or `ExitStatusError`" is present at the top, I didn't internalize what that meant exactly. Therefore, when I got to the panic section, I was mildly confused. This edit makes the behavior more explicitly attached to the type. While the original format had all of the same information available, it was left for the reader to bridge that "making an ExitStatusError" is referring to `ExitStatus::from_raw` as that's the only constructor (for now). Making this bridge more explicit also future-proofs us for future constructors (if they're ever added) that may or may not panic. While the context of the panic documentation is directly attached to `from_raw`, it's slightly (pedantically) more correct to not imply that ANY way of creating an ExitStatusError` from a `wait` of `0` will panic (a different constructor could perhaps return an option instead). Technically, the syntax isn't correct, as it should be `<ExitStatusError as ExitStatusExt>::from_raw`, but I think this conveys intent without being overly verbose. Co-authored-by: Colin Casey <casey.colin@gmail.com>
…xt_chunk_back, r=aapoalas Implement `DoubleEndedIterator::next_chunk_back` This PR builds off on @vinDelphini's [PR](rust-lang#151668) on introducing `DoubleEndedIterator::next_chunk_back` (which will be used in a follow up PR to optimize `ArrayChunks::try_rfold` once merged). This was in the works since late Jan and I thought to pick it up and get this over the finish line as vinDelphini has been away from the PR for a couple of months. I've made sure to pull from vinDelphini's branch to keep him authored on the commits he made. Other things introduced from this PR is specialization like done for `Iterator::next_chunk`, constifying some stuff, making a custom `DoubleEndedIterator::next_chunk_back` for `IntoIter` (since it also has a custom impl of `Iterator::next_chunk`), and a bunch of tests mirroring that of `Iterator::next_chunk`. There's no tracking issue for this yet, but the ACP for this introduction is [here](rust-lang/libs-team#734). I'll create the tracking issue for this soon. ---- Actually, can we have `DoubleEndedIterator::next_chunk_back` underneath [`Iterator::next_chunk` tracking issue](rust-lang#98326)?
std: use `OnceLock` for SGX environment variable storage The SGX environment code predates the existence of `OnceLock` and `AtomicPtr` and consequently violates strict provenance. By using `OnceLock` we can remove all the `unsafe` code (except for the `unsafe` in the function signatures, that's required by other platforms). CC @jethrogb @raoulstrackx @aditijannu
…d, r=aapoalas
Implement `ptr::{read,write}_unaligned` via `repr(packed)`
We already support doing unaligned reads & writes via `repr(packed)` fields, so this just uses that support from the backend rather than needing to thinks about `memcpy` and `intrinsics::forget` and such.
Turns out in codegen this ends up essentially identical because the packed type read gets `BackendRepr::Memory` and thus the read/write of the packed type *is* an `align 1` memcpy, just like the library code before this PR. But doing this gives much simpler MIR and rust-lang#158291 will make it better than the previous version by not needing to emit the `memcpy` at all for things like `read_unaligned::<u32>`.
First commit are some tests that pass on master; Second commit changes the implementation and shows the corresponding test changes.
r? libs
…esleywiser Change `adjust_ident_and_get_scope` arg to `LocalDefId` Addresses a FIXME. Change a HirId to its owner LocalDefId.
…atus-ext, r=Darksonn Clarify ExitStatusExt documentation ## Fix struct links There are several structs (`ExitStatus` and `ExitStatusError`) that could be linked, but aren't. Fixed. All links show their struct now instead of previously some showed `process::ExitStatus` when rendered. ## Add `wait` links The docs distinguish `wait` as code, but do not link to **what** wait they're referring to. As this is Unix extension documentation, adding a link to the POSIX standard for `wait`. Showing a construction of an `ExitStatus` for both a signal and an exit code helps to highlight and internalize what **wait status, not an exit status** means. ## Example for `from_raw` Current documentation calls out "The value should be a **wait status, not an exit status**." but it's unclear what exactly that means without a reference or an example. I added a doctest that shows you need to shift by 8 to get the desired result and annotated it with information about how that's derived based on the linked `wait` documentation. ## Example to `ExitStatus::signal` Called out that a signaled process does not also produce an exit code. Added an example. Called out that just because a process reports that it was not terminated via a signal doesn't mean it never got one (it could be handled). Also added a note correlating shell behavior to exit codes: GNU Bash manual: https://web.archive.org/web/20260625050034/https://www.gnu.org/software/bash/manual/bash.html#Exit-Status-1 > [...] a fatal signal whose number is N, Bash uses the value 128+N as the exit status. FreeBSD bash(1) man page: https://man.freebsd.org/bash/1 > The return value [...] 128+n if the command is terminated by signal n. ## Panic scope on `from_raw` This change is based on preference/experience: When I originally read this documentation, it was because I clicked through `Output` -> `ExitStatus`. While the text "Creates a new `ExitStatus` or `ExitStatusError`" is present at the top, I didn't internalize what that meant exactly. Therefore, when I got to the panic section, I was mildly confused. This edit makes the behavior more explicitly attached to the type. While the original format had all of the same information available, it was left for the reader to bridge that "making an ExitStatusError" is referring to `ExitStatus::from_raw` as that's the only constructor (for now). Making this bridge more explicit also future-proofs us for future constructors (if they're ever added) that may or may not panic. While the context of the panic documentation is directly attached to `from_raw`, it's slightly (pedantically) more correct to not imply that ANY way of creating an ExitStatusError` from a `wait` of `0` will panic (a different constructor could perhaps return an option instead). Technically, the syntax isn't correct, as it should be `<ExitStatusError as ExitStatusExt>::from_raw`, but I think this conveys intent without being overly verbose.
…camelid rustdoc: Show use-site paths for unevaluated const array lengths After rust-lang#158171, I noticed a few additional issues with the rendering of consts in rustdoc. This PR fixes them. When rendering array lengths, avoid inlining the full definition of unevaluated constants via `print_inlined_const`. Instead, fall back to `Const::to_string()` for use-site rendering, matching the behavior already used for projections without bodies. r? camelid
rustc_target/asm: add LoongArch LSX/LASX inline asm register support Add support for LoongArch LSX and LASX registers in inline assembly by introducing the `vreg` and `xreg` register classes, along with their associated vector types and operand modifiers. The new register classes are gated behind the `asm_experimental_reg` feature. Also model the overlap between FPU, LSX, and LASX registers so register conflict checking works correctly for aliased registers.
rustc_sanitizers: use twox-hash without default features We don't need any features from `twox-hash`, and in particular this removes the last use of `rand v0.8` in our lock file.
Rollup of 8 pull requests Successful merges: - rust-lang#156737 (Implement `DoubleEndedIterator::next_chunk_back`) - rust-lang#158180 (std: use `OnceLock` for SGX environment variable storage) - rust-lang#158427 (Implement `ptr::{read,write}_unaligned` via `repr(packed)`) - rust-lang#158531 (Change `adjust_ident_and_get_scope` arg to `LocalDefId`) - rust-lang#158574 (Clarify ExitStatusExt documentation) - rust-lang#158334 (rustdoc: Show use-site paths for unevaluated const array lengths) - rust-lang#158364 (rustc_target/asm: add LoongArch LSX/LASX inline asm register support) - rust-lang#158667 (rustc_sanitizers: use twox-hash without default features)
…4195 Reorganize `tests/ui/issues` [17/N] Part of [GSoC'26 project](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Reorganizing.20tests.2Fui.2Fissues) r? Kivooeo @Teapot4195
…Simulacrum Mirror kernel archives in `ci-mirrors` to not depend on currently unavailable kernel mirror sources ## Summary (Tempoarily) closes rust-lang#158718. See [#t-infra > kernel.org is borked](https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/kernel.2Eorg.20is.20borked/with/608182062). Currently rust-lang/rust CI is borked because: 1. `armhf-gnu` directly tries to download kernel v4.x artifacts from kernel.org mirror, and 2. certain `dist-*` jobs tries to download kernel v3.x and v4.x artifacts from kernel.org mirror indirectly via crosstools-ng ("CT-NG") [^1]. [^1]: Add v5.x but those are already recovered. However, kernel.org mirror sync infra has an active incident (ref: https://status.linuxfoundation.org/incidents/3y1k8b4ky71t) where not all files are available. In particular, v3.x and v4.x kernel artifacts are not recovered yet as of time of writing (check <https://mirrors.edge.kernel.org/pub/linux/kernel/>). ### Mitigation This PR tries to mitigate this by using our own mirrored kernel artifacts from `ci-mirrors` (see rust-lang/ci-mirrors#41, rust-lang/ci-mirrors#42, rust-lang/ci-mirrors#43), such that `linux-$A.$B.$C.tar.gz` artifacts become available as search locations to CT-NG. We carry a patch to CT-NG to use our own `ci-mirrors` artifact SHA256 checksums, the checksum mismatches are as far as we know due to compression setting differences (`ci-mirrors` source archives from <https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/snapshot/>). ## Notes - `armhf-gnu` still has artifacts from third-party mirrors/sources (busybox, ubuntu-base-22.04.2). Not in scope of this PR. - It looks like `3.*` kernel series are considered obselete by CT-NG, and need `CT_OBSOLETE=y` config. - CT-NG checks for known-good kernel versions and checksums against the provided mirror. ### CT-NG known good versions Re. latest kernel versions in each release versus what CT-NG 1.28.0 considers a known good version w/ checksum: Kernel LTS release series | Last release in the series | CT-NG 1.28.0 known good kernel version w/ checksum -- | -- | -- 3.2.* | 3.2.102 | **3.2.101** 3.10.* | 3.10.108 | 3.10.108 4.4.* | 4.4.302 | 4.4.302 4.19.* | 4.19.325 | 4.19.325 4.20.* | 4.20.17 | 4.20.17 5.19.* | 5.19.17 | **5.19.16** (**Bold** CT-NG known good version indicates not latest in release series.) ### `ci-mirrors` kernal tarball SHA256 checksums Refer to https://github.com/rust-lang/ci-mirrors/blob/b474b4bb35108dab668907172c858854f209c809/files/rustc/kernel.toml: | **Kernel Version** | **SHA256** | | ------------------ | ------------------------------------------------------------------ | | 3.2.101 | `93e8391e029f131d5ba4b7ad76cc34b12f2c2244059604042f2297c4bde093f7` | | 3.10.108 | `b1711610cf3faf7194156dacdb98c63c1b7ffd02377269d7f75df63d823ccbba` | | 4.4.302 | `a22ceab143d40f511203265e5a70d6cc5ec39163cd54fa281346d19176f64451` | | 4.19.325 | `8753443636e475b506e08abd40059ec9b84904a115d206014f0c856dfe13a25e` | | 4.20.17 | `313b7bebb46084efbfcaf75f4ea6faf2e14c8cbc1711fcba483dc0a036c9acc1` | | 5.19.16 | `bbf0ead65559250e0784c13d4f9716b7f917a1d3a4e00f671f3994cc6990bb02` | --- try-job: armhf-gnu try-job: dist-armhf-linux try-job: dist-arm-linux-gnueabi try-job: dist-powerpc64le-linux-musl try-job: dist-loongarch64-musl try-job: dist-riscv64-linux try-job: dist-powerpc64le-linux-gnu try-job: dist-powerpc64-linux-musl try-job: dist-armv7-linux try-job: dist-powerpc-linux try-job: dist-loongarch64-linux try-job: dist-s390x-linux try-job: dist-i586-gnu-i586-i686-musl try-job: dist-powerpc64-linux-gnu
Update cargo submodule 13 commits in a335d47ff8036918d3d548dabd513dc0444096a9..f40cc7a13a8ebe3dd0a35b1e0e37a1e26c8bb0e5 2026-06-26 20:39:41 +0000 to 2026-07-01 18:57:21 +0000 - chore(deps): update rust crate gix to 0.85.0 (rust-lang/cargo#17159) - Fixed `Compilation::deps_output` only taking the last dep (rust-lang/cargo#17164) - chore(deps): update taiki-e/install-action action to v2.82.7 (rust-lang/cargo#17163) - chore(deps): update rust crate rusqlite to 0.40.0 (rust-lang/cargo#17162) - chore(deps): update rust crate itertools to 0.15.0 (rust-lang/cargo#17160) - chore(deps): update compatible (rust-lang/cargo#17156) - chore(deps): update crate-ci/typos action to v1.48.0 (rust-lang/cargo#17158) - chore(deps): update alpine docker tag to v3.24 (rust-lang/cargo#17157) - chore(deps): update actions/checkout action to v6.0.3 (rust-lang/cargo#17155) - chore: upgrade to libssh2-sys@0.3.2 (rust-lang/cargo#17152) - test(help): Don't hang on Mac with a custom man pager (rust-lang/cargo#17151) - docs(lints): Add a false-positive example solution (rust-lang/cargo#17147) - docs(lints): Reduce the superfluous whitespace by grouping bullet items (rust-lang/cargo#17146) r? ghost
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
20 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.
Tracking issue: rust-lang#74265
This PR makes the safety documentation for raw pointer and NonNull
get_unchecked(_mut)APIs more consistent.Currently,
*mut [T]::get_unchecked_mutlinksout-of-bounds indexto theaddmethod, but the corresponding docs for*const[T]::get_uncheckedandNonNull<[T]>::get_unchecked_mutuse plain text for the same safety condition.This PR updates those two docs to link
out-of-bounds indexto#method.add, matching the existing wording and link style used by*mut [T]::get_unchecked_mut.This is a documentation-only change.
I also noticed that similar wording in the following APIs currently does not link
out-of-bounds index:I did not update those in this PR because I am not sure which target would be the most appropriate link for those APIs. If there
is a preferred link target for these slice and
SliceIndexdocs, I would be happy to update them and merge the updates in this PR.