typeck: catch `continue`s pointing to blocks
This taints the typeck results with errors if a `continue` is found not pointing to a loop.
A few things were going wrong here. First, since this wasn't caught in typeck, we'd end up building the THIR and then running liveness lints on ill-formed HIR. Since liveness assumes all `continue`s point to loops, it wasn't setting a live node for the `continue`'s destination. There was a fallback for if it couldn't retrieve that live node, but it was faulty; it would create a new live node to represent an erroneous state after the analysis's RWU table had already been built. This would ICE if the new live node was used in operations, such as merging results from the arms of a match. I've removed this error-recovery since it was buggy, and we should really catch bad labels before liveness.
I've also replaced an outdated comment about when liveness lints are run. At this point, I think the call to `check_liveness` could be moved elsewhere, but if it can be run when the typeck results are tainted by errors, it'll need some slight refactoring so it can bail out in that case. In lieu of that, I've added an assert.
Fixes#113379Fixes#121623
Allow trailing comma after argument in query definition
Don't catastrophically fail the query macro if you put a comma after your query key!
r? oli-obk
Suggest use "{}", self.x instead of {self.x} when resolve x as field of `self`
Fixes#141136
Changes can be seen in the second commit: 9de7fff0d8
r? compiler
Add `std::os::unix::process::CommandExt::chroot` to safely chroot a child process
This adds a `chroot` method to the `CommandExt` extension trait for the
`Command` builder, to set a directory to chroot into. This will chroot
the child process into that directory right before calling chdir for the
`Command`'s working directory.
To avoid allowing a process to have a working directory outside of the
chroot, if the `Command` does not yet have a working directory set,
`chroot` will set its working directory to "/".
---
ACP: https://github.com/rust-lang/libs-team/issues/551
This PR currently has the tracking issue set to "none"; if the ACP is approved,
I'll file a tracking issue and update the PR.
Since the mode is no longer part of `meta_item`, we must insert it manually (otherwise macro expansion with `#[rustc_autodiff]` won't work).
This can be revised later if a more structured representation becomes necessary (using enums, annotated structs, etc).
Some tests are currently failing. I'll address them next.
Update books
## rust-lang/edition-guide
1 commits in 1b1bb49babd65c732468cfa515b0c009bd1d26bc..aa6ce337c0adf7a63e33960d184270f2a45ab9ef
2025-05-20 23:47:34 UTC to 2025-05-20 23:47:34 UTC
- Update references to the `missing_fragment_specifier` lint (rust-lang/edition-guide#376)
## rust-lang/reference
3 commits in acd0231ebc74849f6a8907b5e646ce86721aad76..118fd1f1f0854f50e3ae1fe4b64862aad23009ca
2025-05-20 22:52:38 UTC to 2025-05-20 21:45:13 UTC
- Explain why nested receivers are dyn-incompatible (rust-lang/reference#1822)
- Enable `[canonicalize-issue-links]` and `[no-mentions]` in triagebot (rust-lang/reference#1788)
- Mention the temporary scope of `while let`. (rust-lang/reference#1779)
Implement `ptr::try_cast_aligned` and `NonNull::try_cast_aligned`.
Implement three common methods on raw pointers and `NonNull`s: `try_cast_aligned`.
## Related links
- Tracking Issue: https://github.com/rust-lang/rust/issues/141221
## About `#[inline]`
Since the result of a call to `align_of` is a power of two known at compile time, the compiler is able to reduce a call to `try_cast_aligned` to only test and sete (or test and jne if followed by `unwrap`), at least on every tier 1 target's arch. This seemed like a good reason to `#[inline]` the function.
- https://godbolt.org/z/ocehvPWMx (raw inlining)
- https://godbolt.org/z/3qa4j4Yrn (comparison with no inlining)
Add match guard let chain drop order and scoping tests
We have a bunch of tests for if let chain drop order, but those tests don't cover match guard chains to the same depth. This PR adds the following tests:
* match guard equivalents of the if let chains tests in the `drop-order-comparisons.rs` test, added by #133605.
* match guard equivalent of the `mir_let_chains_drop_order.rs` test, added by #107251
* match guard equivalent of `temporary-early-drop.rs`, added by #133093
The added tests all have variants for 2021 and 2024, showing that the behavior on both editions matches that of if let chains on 2024.
tracking issue: https://github.com/rust-lang/rust/issues/51114
collect doc alias as tips during resolution
Close#124273
Collect the symbol in the doc alias attributes and provide a tip when a match is found.
r? `@estebank`
This taints the typeck results with errors if a `continue` is found not
pointing to a loop, which fixes an ICE.
A few things were going wrong here. First, since this wasn't caught in
typeck, we'd end up building the THIR and then running liveness lints on
ill-formed HIR. Since liveness assumes all `continue`s point to loops,
it wasn't setting a live node for the `continue`'s destination. However,
the fallback for this was faulty; it would create a new live node to
represent the erroneous state after the analysis's RWU table had already
been built. This would ICE if the new live node was used in operations,
such as merging results from the arms of a match. I've removed this
error-recovery since it was buggy, and we should really catch bad labels
before liveness.
I've also replaced an outdated comment about when liveness lints are
run. At this point, I think the call to `check_liveness` could be moved
elsewhere, but if it can be run when the typeck results are tainted by
errors, it'll need some slight refactoring so it can bail out in that
case. In lieu of that, I've added an assertion.
The first commit fixesrust-lang/rust-clippy#14802: when a slice is
directly present, it must be dereferenced (instead of referenced -1
times) before being passed to `mem::size_of_val()`.
The second commit triggers the lint in a `const` contact when MSRV ≥
1.85.
changelog: [`manual_slice_size_computation`]: fix ICE in suggestion to
efficiently compute the size of a slice, and trigger the lint in `const`
context as well
The `explicit_into_iter_loop`, `explicit_iter_loop` and `iter_next_loop`
will now:
- trigger only when the triggering expression is not located into macro
code;
- properly expose code rewrite proposal with code coming from the root
context.
changelog: [`explicit_into_iter_loop`, `explicit_iter_loop`,
`iter_next_loop`]: behave in macro context
Fixesrust-lang/rust-clippy#14630
[win][ci] Update LLVM toolchain used to build LLVM to 20
While trying to get the aarch64-msvc build working correctly (#140136), I needed to update the version of LLVM used to build LLVM in Windows CI runners to 20 (as this has improved support for Arm64 and Arm64EC on Windows).
This catches Windows up to Linux which was updated to 20 by #137189
try-job: `x86_64-apple-*`
try-job: `aarch64-apple`
try-job: `x86_64-msvc-*`
try-job: `i686-msvc-*`
try-job: `x86_64-mingw-*`
use `Self` alias in self types rather than manually substituting it
Of the rougly 145 uses of `self: Ty` in the standard library, 5 of them don't use `Self` but instead choose to manually "substitute" the `impl`'s self type into the type.
This leads to weird behavior sometimes (https://github.com/rust-lang/rust/issues/140611#issuecomment-2883761300) -- **to be clear**, none of these usages actually trigger any bugs, but it's possible that they may break in the future (or at least lead to lints), so let's just "fix" them proactively.
