remove `feature(inline_const_pat)`
Summarizing https://rust-lang.zulipchat.com/#narrow/channel/144729-t-types/topic/remove.20feature.28inline_const_pat.29.20and.20shared.20borrowck.
With https://github.com/rust-lang/types-team/issues/129 we will start to borrowck items together with their typeck parent. This is necessary to correctly support opaque types, blocking the new solver and TAIT/ATPIT stabilization with the old one. This means that we cannot really support `inline_const_pat` as they are implemented right now:
- we want to typeck inline consts together with their parent body to allow inference to flow both ways and to allow the const to refer to local regions of its parent.This means we also need to borrowck the inline const together with its parent as that's necessary to properly support opaque types
- we want the inline const pattern to participate in exhaustiveness checking
- to participate in exhaustiveness checking we need to evaluate it, which requires borrowck, which now relies on borrowck of the typeck root, which ends up checking exhaustiveness again. **This is a query cycle**.
There are 4 possible ways to handle this:
- stop typechecking inline const patterns together with their parent
- causes inline const patterns to be different than inline const exprs
- prevents bidirectional inference, we need to either fail to compile `if let const { 1 } = 1u32` or `if let const { 1u32 } = 1`
- region inference for inline consts will be harder, it feels non-trivial to support inline consts referencing local regions from the parent fn
- inline consts no longer participate in exhaustiveness checking. Treat them like `pat if pat == const { .. }` instead. We then only evaluate them after borrowck
- difference between `const { 1 }` and `const FOO: usize = 1; match x { FOO => () }`. This is confusing
- do they carry their weight if they are now just equivalent to using an if-guard
- delay exhaustiveness checking until after borrowck
- should be possible in theory, but is a quite involved change and may have some unexpected challenges
- remove this feature for now
I believe we should either delay exhaustiveness checking or remove the feature entirely. As moving exhaustiveness checking to after borrow checking is quite complex I think the right course of action is to fully remove the feature for now and to add it again once/if we've got that implementation figured out.
`const { .. }`-expressions remain stable. These seem to have been the main motivation for https://github.com/rust-lang/rfcs/issues/2920.
r? types
cc `@rust-lang/types` `@rust-lang/lang` #76001
Update target maintainers for thumb targets to reflect new REWG Arm team name
Closes#139027
The name of the team responsible for these targets has changed as the team was merged with other Arm-related teams (see https://github.com/rust-embedded/wg/pull/818). The link gives an up-to-date list of github usernames that can be pinged, whereas the old email address is not very actively maintained or tracked.
Improve `xcrun` error handling
The compiler invokes `xcrun` on macOS when linking Apple targets, to find the Xcode SDK which contain all the necessary linker stubs. The error messages that `xcrun` outputs aren't always that great though, so this PR tries to improve that by providing extra context when an error occurs.
Fixes https://github.com/rust-lang/rust/issues/56829.
Fixes https://github.com/rust-lang/rust/issues/84534.
Part of https://github.com/rust-lang/rust/issues/129432.
See also the alternative https://github.com/rust-lang/rust/pull/131433.
Tested on:
- `x86_64-apple-darwin`, MacBook Pro running Mac OS X 10.12.6
- With no tooling installed
- With Xcode 9.2
- With Xcode 9.2 Commandline Tools
- `aarch64-apple-darwin`, MacBook M2 Pro running macOS 14.7.4
- With Xcode 13.4.1
- With Xcode 16.2
- Inside `nix-shell -p xcbuild` (nixpkgs' `xcrun` shim)
- `aarch64-apple-darwin`, VM running macOS 15.3.1
- With no tooling installed
- With Xcode 16.2 Commandline Tools
``@rustbot`` label O-apple
r? compiler
CC ``@BlackHoleFox`` ``@thomcc``
I've intentionally used slightly vague language ("roughly"), as we don't
want to guarantee the exact invocation of `xcrun`, just hint that it's
close to that.
Add target maintainer information for powerpc64-unknown-linux-musl
We intend to fix the outstanding issues on the target and eventually promote it to tier 2. We have the capacity to maintain this target in the future and already perform regular builds of rustc for this target.
Currently, all host tools except miri build fine, but I have a patch for libffi-sys to make miri also compile fine for this target that is [pending review](https://github.com/tov/libffi-rs/pull/100).
While at it, add an option for the musl root for this target.
I also added a kernel version requirement, which is rather arbitrarily chosen, but it matches our tier 2 powerpc64le-unknown-linux-musl target so I think it is a good fit.
We intend to fix the outstanding issues on the target and eventually
promote it to tier 2. We have the capacity to maintain this target in
the future and already perform regular builds of rustc for this target.
Currently, all host tools except miri build fine, but I have a patch for
libffi-sys to make miri also compile fine for this target that is
pending review [1].
While at it, add an option for the musl root for this target.
[1]: https://github.com/tov/libffi-rs/pull/100
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
Update books
## rust-lang/book
23 commits in 81a976a237f84b8392c4ce1bd5fd076eb757a2eb..45f05367360f033f89235eacbbb54e8d73ce6b70
2025-03-21 23:23:52 UTC to 2025-03-13 14:14:37 UTC
- Ch. 21: call out Chrome multiple-connections issue (rust-lang/book#4297)
- Ch. 16: refactor 16-6 to using listing component (rust-lang/book#4295)
- Ch. 01: Show how to work offline (rust-lang/book#4294)
- Ch. 07: Clarify sentences about `pub use` (rust-lang/book#4293)
- Ch. 02: Consistent ordering of `use` statements (rust-lang/book#4292)
- Anchors on listings (rust-lang/book#4271)
- Ch. 17: another tweak to how we phrase things about sections (rust-lang/book#4288)
- Ch. 20: correct listing number (rust-lang/book#4287)
- Ch. 10.3: clarify language detail (rust-lang/book#4284)
- Ch. 17: minor typos and link reference (rust-lang/book#4286)
- Ch. 9: correctly demonstrate privacy with module (rust-lang/book#4282)
- Ch. 18: correct discussion of delegation in `Post` methods (rust-lang/book#4281)
- Ch. 20: tell folks to see the Reference for more ABI info (rust-lang/book#4165)
- Ch 10.1 minor clarifications (rust-lang/book#4256)
- Clarified the misunderstanding b/w crates, module, items (rust-lang/book#4232)
- Ferris: always show, even when it’s small (rust-lang/book#4280)
- Ch. 17: mention `use std::pin::{Pin, pin};` on introduction (rust-lang/book#4279)
- Persist printing error, NOT ErrorKind (rust-lang/book#4259)
- Typo: "2" should be "2 seconds" (rust-lang/book#4263)
- Ch. 17: fix tiny example consistency issue (rust-lang/book#4270)
- Bump ring from 0.17.8 to 0.17.13 in /listings/ch17-async-await/listing-17-02 (rust-lang/book#4261)
- Bump ring from 0.17.8 to 0.17.14 in /packages/trpl (rust-lang/book#4273)
- 2024 Print Edition: updates to Word docs and more fixes to Markdown text (rust-lang/book#4272)
## rust-lang/reference
5 commits in dda31c85f2ef2e5d2f0f2f643c9231690a30a626..e95ebdfee02514d93f79ec92ae310a804e87f01f
2025-03-24 15:56:46 UTC to 2025-03-18 02:25:06 UTC
- Fix diagnostic attribute typo (rust-lang/reference#1767)
- Mention that “every address” ≠ “every pointer” (rust-lang/reference#1761)
- Rework range pattern rules (rust-lang/reference#1756)
- Use warning block in behavior-considered-undefined (rust-lang/reference#1759)
- Add reference for asm-goto (rust-lang/reference#1693)
Rework `--print` options documentation
This PR reworks the `--print` options documentation, by making it more like codegen options with a dedicated page.
I also added some examples and split some paragraph into multiple paragraph since we now have more place.
r? ```@jieyouxu```
Rollup of 7 pull requests
Successful merges:
- #138384 (Move `hir::Item::ident` into `hir::ItemKind`.)
- #138508 (Clarify "owned data" in E0515.md)
- #138531 (Store test diffs in job summaries and improve analysis formatting)
- #138533 (Only use `DIST_TRY_BUILD` for try jobs that were not selected explicitly)
- #138556 (Fix ICE: attempted to remap an already remapped filename)
- #138608 (rustc_target: Add target feature constraints for LoongArch)
- #138619 (Flatten `if`s in `rustc_codegen_ssa`)
r? `@ghost`
`@rustbot` modify labels: rollup
Only use `DIST_TRY_BUILD` for try jobs that were not selected explicitly
Some CI jobs (x64 Linux, ARM64 Linux and x64 MSVC) use the `opt-dist` tool to build an optimized toolchain using PGO and BOLT. When performing a default try build for x64 Linux, in most cases we want to run perf. on that artifact. To reduce the latency of this common use-case, `opt-dist` skips building several components not needed for perf., and it also skips running post-optimization tests, when it detects that the job is executed as a try job (not a merge/auto job).
This is useful, but it also means that if you *want* to run the tests, you had to go to `jobs.yml` and manually comment this environment variable, create a WIP commit, do a try build, and then remove the WIP commit, which is annoying (in the similar way that modifying what gets run in try builds was annoying before we had the `try-job` annotations).
I thought that we could introduce some additional PR description marker like `try-job-run-tests`, but it's hard to discover that such things exist.
Instead, I think that there's a much simpler heuristic for determining whether `DIST_TRY_BUILD` should be used (that I implemented in this PR):
- If you do just ``@bors` try`, without any custom try jobs selected, `DIST_TRY_BUILD` will be activated, to finish the build as fast as possible.
- If you specify any custom try jobs, you are most likely doing experiments and you want to see if tests pass and everything builds as it should. The `DIST_TRY_BUILD` variable will thus *not* be set in this case.
In this way, if you want to run dist tests, you can just add the `try-job: dist-x86_64-linux` line to the PR description, and you don't need to create any WIP commits.
r? `@marcoieni`
change config.toml to bootstrap.toml
Currently, both Bootstrap and Cargo uses same name as their configuration file, which can be confusing. This PR is based on a discussion to rename `config.toml` to `bootstrap.toml` for Bootstrap. Closes: https://github.com/rust-lang/rust/issues/126875.
I have split the PR into atomic commits to make it easier to review. Once the changes are finalized, I will squash them. I am particularly concerned about the changes made to modules that are not part of Bootstrap. How should we handle those changes? Should we ping the respective maintainers?
Stabilize `asm_goto` feature gate
Stabilize `asm_goto` feature (tracked by #119364). The issue will remain open and be updated to track `asm_goto_with_outputs`.
Reference PR: https://github.com/rust-lang/reference/pull/1693
# Stabilization Report
This feature adds a `label <block>` operand type to `asm!`. `<block>` must be a block expression with type unit or never. The address of the block is substituted and the assembly may jump to the block. When block completes the `asm!` block returns and continues execution.
The block starts a new safety context and unsafe operations within must have additional `unsafe`s; the effect of `unsafe` that surrounds `asm!` block is cancelled. See https://github.com/rust-lang/rust/issues/119364#issuecomment-2316037703 and https://github.com/rust-lang/rust/pull/131544.
It's currently forbidden to use `asm_goto` with output operands; that is still unstable under `asm_goto_with_outputs`.
Example:
```rust
unsafe {
asm!(
"jmp {}",
label {
println!("Jumped from asm!");
}
);
}
```
Tests:
- tests/ui/asm/x86_64/goto.rs
- tests/ui/asm/x86_64/goto-block-safe.stderr
- tests/ui/asm/x86_64/bad-options.rs
- tests/codegen/asm/goto.rs
