Rollup of 3 pull requests
Successful merges:
- rust-lang/rust#150058 (Enable file locking support for Hurd)
- rust-lang/rust#150420 (Do not spill operand debuginfo to stack for AArch64 SVE predicates `<vscale x N x i1>` where `N != 16`)
- rust-lang/rust#150501 (Fix Typos in Platform Support Tables)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix Typos in Platform Support Tables
3 recently demoted targets had their entries moved to the tier 3 table without adjusting for the extra "host" column, this PR adds an empty column so they display correctly.
2 recently promoted targets had the opposite problem, also fixed.
While doing that I noticed that empty columns were represented inconsistently throughout the file so I normalized them all to be 2 spaces, which seemed to be the majority opinion (139 instances vs 5 for 1 space and 19 for 3 spaces).
Closes: rust-lang/rust#150499
Enable file locking support for Hurd
like Illumos (rust-lang/rust#148322) and aix (rust-lang/rust#148619), Hurd was missed when originally
introducing locking gates per target OS in rust-lang/rust#132977. building rustc on Hurd was
broken as a result since 1.91.
Rollup of 2 pull requests
Successful merges:
- rust-lang/rust#150422 (mir_build: Add a `SliceLenOp` enum for use by slice-length cases/tests)
- rust-lang/rust#150509 (Adds a regression test for rust-lang/rust#137823)
r? `@ghost`
`@rustbot` modify labels: rollup
Adds a regression test for #137823
Adds a regression test for rust-lang/rust#137823. The test ensures that recursive generic function instantiation properly triggers the recursion limit error instead of ICE-ing with `type variables should not be hashed`.
Closesrust-lang/rust#137823
mir_build: Add a `SliceLenOp` enum for use by slice-length cases/tests
The main change in this PR introduces a `SliceLenOp` enum, to be used by the enum variants for slice-length tests in match lowering.
Slice-length tests must distinguish between `==` tests, and `>=` tests. The existing code represents this distinction with either a boolean (in `TestableCase`) or a `mir::BinOp` (in `TestKind`). Using a dedicated enum makes it easier to see what the two possible values represent.
This PR also includes a few relevant cleanups that would otherwise conflict.
r? Nadrieril
Cleanup linked list
- Replaces some checked_sub().unwrap_or(0) with saturating_sub().
- Replaces NonNull::from(Box::leak(node)) with Box::into_non_null(node)
Simplify `TypeFreshener` methods.
`freshen_{ty,const}` take a `Result` and just do a fold if the input is `Ok`. It's simpler to do those folds at the call site, and only call `freshen_{ty,const}` in the `Err` case. That way we can also avoid useless fold operations on the results of `new_{int,uint,float}`.
Also, make some `bug!` calls more concise.
r? `@lcnr`
mir_build: Remove several remnants of `#![feature(inline_const_pat)]`
This PR cleans up some THIR-related code that was only needed for inline `const { .. }` blocks in patterns. The `inline_const_pat` feature was removed in https://github.com/rust-lang/rust/pull/138492 due to implementation concerns.
I considered retaining the code for preserving `ExpandedConstant` for range endpoints, but ultimately decided to remove that too, because I found it very awkward to document an edge case that is currently not needed by any subsequent code.
With this PR, `is_const_pat_that_looks_like_binding` is the only function that meaningfully consumes `thir::PatKind::ExpandedConst`.
Mark set_times as unavailable for RTEMS target
This PR just updates one of the config switches to exclude `utimesat` for the RTEMS target.
This currently creates undefined reference errors when building the target.
With this fix applied it also needs a fix in libc (see https://github.com/rust-lang/libc/pull/4875) which will hopefully be available in release 0.2.179.
Implement `TryFrom<char>` for `usize`.
Feature gate: `usize_try_from_char`.
This PR implements `TryFrom<char>` for `usize`.
`usize` is currently the only, unsigned, integral type to not implement `TryFrom<char>`. Technically, this conversion is trivial and can already be expressed with some indirection.
I think it useful to be able to describe this set of types with this interface.
Remove the explicit branch hint from const_panic
This was asked for in PR review for equivalence with `assert!`, but we don't need likely/unlikely intrinsics here (and indeed they are a bit of an antipattern), because codegen knows about the pattern that `assert!` produces where only one target of a SwitchInt leads to a block terminated by a `#[cold]` call. All our panic entrypoints are `#[cold]`.
`assert!` does not use the likely/unlikely intrinsics, maybe it did in the past.
So the intrinsic call in `const_assert!` should be completely unnecessary. But currently it isn't, because `const_panic!` stamps out a runtime wrapper for its entrypoint which is not given `#[inline]`, citing compile times. It's not obvious to me why not using `#[inline]` would even be good in this case.
I think the runtime wrapper should have `#[inline]` or `#[cold]`, so I'm going to do 3 perf experiments here.
Just changing `const_assert!`: https://perf.rust-lang.org/compare.html?start=fabece9e9491d0a3c3655dba488881968b7c5f7a&end=f6b082cfcf880ad80b33523d5047c11654d907a8&stat=instructions:u
Also adding `#[inline]` to `const_panic!`'s runtime wrapper: https://perf.rust-lang.org/compare.html?start=fabece9e9491d0a3c3655dba488881968b7c5f7a&end=f467cc7e49b74b47da0e2cde49fc1a3140e00ff6&stat=instructions:u
Also adding `#[cold]` to `const_panic!`'s runtime wrapper: https://perf.rust-lang.org/compare.html?start=2e854a9344154564259de51385e9ec9506c0f3b7&end=fd8e098558ff08ac002b05ff78e9f91ffa6f3738&stat=instructions:u
The previous comment indicated perf would be worse with `#[inline]` on the runtime branch, but the results in this PR show that it is more mixed, and net positive. And in fact, the only regression in serde seems to be because we created a very tiny additional amount of codegen, but pushed the size of the second CGU just high enough that we no longer merge all CGUs together. So now serde (in debug with incremental disabled) has 2 CGUs instead of 1. If we just so happened to be still below the threshold where the CGUs don't merge, adding `#[inline]` would have been nearly all improvements.
Rollup of 3 pull requests
Successful merges:
- rust-lang/rust#150396 ([rustdoc] If line number setting is disabled, do not make line numbers take space)
- rust-lang/rust#150489 (Disable debuginfo when building GCC)
- rust-lang/rust#150490 (Specify bug URL when building GCC)
r? `@ghost`
`@rustbot` modify labels: rollup
[rustdoc] If line number setting is disabled, do not make line numbers take space
While working on https://github.com/rust-lang/rust/pull/150395, I realized that when enabled then disabled the "show line numbers" setting, instead of looking like initially:
<img width="904" height="148" alt="Screenshot From 2025-12-26 16-51-44" src="https://github.com/user-attachments/assets/a24df2f2-61be-4db5-b60f-519b35425fd2" />
The "space" taken by line numbers was still there:
<img width="904" height="148" alt="Screenshot From 2025-12-26 16-51-41" src="https://github.com/user-attachments/assets/b44af75d-52a4-4401-98e4-602b16bf6b9b" />
This PR fixes it.
First commit cleans up the `utils.goml` file a bit, I think I'll do more cleanup because switching the settings without reloading the page should make GUI tests a bit faster.
r? `@yotamofek`
alloc: specialize String::extend for slices of str
Here's a small optimization via specialization that can potentially eliminate a fair few reallocations when building strings using specific patterns, unsure if this justifies the use of unsafe, but I had the code implemented from rust-lang/rust#148604, so I thought it was worth submitting to see.
Accommodate LLVM PassPlugin rename
LLVM [recently moved](https://github.com/llvm/llvm-project/pull/173279) their `PassPlugin` files to a new folder. This PR updates our `PassWrapper` to point to the new location.
bootstrap: Use cargo's `build.warnings=deny` rather than -Dwarnings
This has two major advantages. First, it makes us less dependent on the rustc shim, which is nice but not super important. More importantly, it gives us much nicer caching properties.
Previously, `x build --warnings warn && x build --warnings deny` would rebuild all of bootstrap, and if there were any warnings emitted on the last build of the compiler, they would *not* fail the build, because cargo would cache the output rather than rerunning the shim.
After this change, bootstrap rebuilds instantly, and cargo knows that it should fail the build but *without* invalidating the cache.
<details><summary>An example of rebuilding bootstrap after a switch from warn->deny:</summary>
```
INFO: Downloading and building bootstrap before processing --help command.
See src/bootstrap/README.md for help with common commands.
Building bootstrap
Compiling bootstrap v0.0.0 (/Users/jyn/src/ferrocene3/src/bootstrap)
warning: unused variable: `x`
--> src/bootstrap/src/core/builder/mod.rs:1792:13
|
1792 | let x: ();
| ^
|
= note: `#[warn(unused_variables)]` (part of `#[warn(unused)]`) on by default
help: if this is intentional, prefix it with an underscore
|
1792 | let _x: ();
| +
help: you might have meant to pattern match on the similarly named constant `_`
|
1792 - let x: ();
1792 + let utils::render_tests::_: ();
|
warning: `bootstrap` (lib) generated 1 warning (run `cargo fix --lib -p bootstrap` to apply 1 suggestion)
Finished `dev` profile [unoptimized] target(s) in 5.14s
error: warnings are denied by `build.warnings` configuration
failed to run: /Users/jyn/src/ferrocene3/build/aarch64-apple-darwin/stage0/bin/cargo build --jobs=default --manifest-path /Users/jyn/src/ferrocene3/src/bootstrap/Cargo.toml -Zroot-dir=/Users/jyn/src/ferrocene3 -Zwarnings
```
</details>
building the compiler from scratch with `deny`: https://gist.github.com/jyn514/493ed26c2aa6f61bf47c21e75efa2175
<details><summary>and rebuilding the compiler after switching from deny->warn (note that it reuses the whole cache, there are no invalidations):</summary>
```
$ x c compiler
Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.15s
Checking stage1 compiler artifacts{rustc-main, rustc_abi, rustc_arena, rustc_ast, rustc_ast_ir, rustc_ast_lowering, rustc_ast_passes, rustc_ast_pretty, rustc_attr_parsing, rustc_baked_icu_data, rustc_borrowck, rustc_builtin_macros, rustc_codegen_llvm, rustc_codegen_ssa, rustc_const_eval, rustc_data_structures, rustc_driver, rustc_driver_impl, rustc_error_codes, rustc_error_messages, rustc_errors, rustc_expand, rustc_feature, rustc_fluent_macro, rustc_fs_util, rustc_graphviz, rustc_hashes, rustc_hir, rustc_hir_analysis, rustc_hir_id, rustc_hir_pretty, rustc_hir_typeck, rustc_incremental, rustc_index, rustc_index_macros, rustc_infer, rustc_interface, rustc_lexer, rustc_lint, rustc_lint_defs, rustc_llvm, rustc_log, rustc_macros, rustc_metadata, rustc_middle, rustc_mir_build, rustc_mir_dataflow, rustc_mir_transform, rustc_monomorphize, rustc_next_trait_solver, rustc_parse, rustc_parse_format, rustc_passes, rustc_pattern_analysis, rustc_privacy, rustc_proc_macro, rustc_public, rustc_public_bridge, rustc_query_impl, rustc_query_system, rustc_resolve, rustc_sanitizers, rustc_serialize, rustc_session, rustc_span, rustc_symbol_mangling, rustc_target, rustc_thread_pool, rustc_trait_selection, rustc_traits, rustc_transmute, rustc_ty_utils, rustc_type_ir, rustc_type_ir_macros, rustc_windows_rc} (stage0 -> stage1, aarch64-apple-darwin)
warning: function `foo` is never used
--> compiler/rustc_hashes/src/lib.rs:16:4
|
16 | fn foo() {}
| ^^^
|
= note: `#[warn(dead_code)]` (part of `#[warn(unused)]`) on by default
warning: `rustc_hashes` (lib) generated 1 warning
Finished `release` profile [optimized + debuginfo] target(s) in 0.53s
Build completed successfully in 0:00:08
```
</details>
thanks to `@epage` for the help finding this!
r? bootstrap
Fix enum variant suggestion consuming trailing parenthesis
- Closesrust-lang/rust#150459
Previously the logic incorrectly assumed the variant itself was the function being called when the parent node was a function all. This change adds a check to ensure the replacement span is only expanded if the path expression is actually the callee of the parent expression.
Offload: Build offload as a single Step
r? `@Kobzol`
Since it looks like we'll postpone enabling offload in CI for a bit, I factored out these improvements which we want independently. I locally tested both build options successfully, the in-tree-clang build, as well as the build where we provide a path to an external clang.
paradoxicalguy