Re-implement a type-size based limit #125507

compiler-errors · 2024-05-24T18:15:15Z

r? lcnr

This PR reintroduces the type length limit added in #37789, which was accidentally made practically useless by the caching changes to Ty::walk in #72412, which caused the walk function to no longer walk over identical elements.

Hitting this length limit is not fatal unless we are in codegen -- so it shouldn't affect passes like the mir inliner which creates potentially very large types (which we observed, for example, when the new trait solver compiles itertools in --release mode).

This also increases the type length limit from 1048576 == 2 ** 20 to 2 ** 24, which covers all of the code that can be reached with craterbot-check. Individual crates can increase the length limit further if desired.

Perf regression is mild and I think we should accept it -- reinstating this limit is important for the new trait solver and to make sure we don't accidentally hit more type-size related regressions in the future.

Fixes #125460

compiler-errors · 2024-05-24T18:15:34Z

@bors try @rust-timer queue

bors · 2024-05-24T18:16:44Z

⌛ Trying commit 6ae5d95 with merge 5f700d6...

…=<try> Re-implement a type-size based limit r? lcnr Fixes rust-lang#125460

compiler-errors · 2024-05-24T18:28:25Z

@bors try

bors · 2024-05-24T18:29:35Z

⌛ Trying commit 09b9c08 with merge 61a9ac6...

…=<try> Re-implement a type-size based limit r? lcnr Fixes rust-lang#125460

bors · 2024-05-24T20:02:40Z

☀️ Try build successful - checks-actions
Build commit: 61a9ac6 (61a9ac64344e91d62f5496627ff363d177f9daab)

compiler-errors · 2024-05-24T20:29:53Z

@craterbot run mode=build-and-test

craterbot · 2024-05-24T20:30:00Z

👌 Experiment pr-125507 created and queued.
🤖 Automatically detected try build 61a9ac6
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

rust-timer · 2024-05-24T21:42:51Z

Finished benchmarking commit (61a9ac6): comparison URL.

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf perf-regression

Warning ⚠: The following benchmark(s) failed to build:

deeply-nested-multi

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	1.2%	[0.4%, 1.9%]	6
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.2%	[-0.2%, -0.2%]	1
Improvements ✅ (secondary)	-0.6%	[-1.0%, -0.3%]	4
All ❌✅ (primary)	1.0%	[-0.2%, 1.9%]	7

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 674.001s -> 680.65s (0.99%)
Artifact size: 315.67 MiB -> 315.56 MiB (-0.04%)

craterbot · 2024-05-28T16:39:36Z

🚧 Experiment pr-125507 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

craterbot · 2024-05-30T14:16:12Z

🎉 Experiment pr-125507 is completed!
📊 374 regressed and 126 fixed (465734 total)
📰 Open the full report.

⚠️ If you notice any spurious failure please add them to the blacklist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

lcnr · 2024-05-30T14:25:36Z

want to try bumping the limit x10 and rerun crater?

cache type sizes in type-size limit visitor This is rust-lang#125507 (comment) as lcnr can't open the PR now. Locally it reduces the `itertools` regression by quite a bit, "only 50%" compared to nightly. ```console Benchmark 1: cargo stage1 build --release Time (mean ± σ): 2.721 s ± 0.009 s [User: 2.446 s, System: 0.325 s] Range (min … max): 2.710 s … 2.738 s 10 runs Benchmark 2: cargo nightly build --release Time (mean ± σ): 1.784 s ± 0.005 s [User: 1.540 s, System: 0.279 s] Range (min … max): 1.778 s … 1.792 s 10 runs Summary cargo nightly build --release ran 1.52 ± 0.01 times faster than cargo stage1 build --release ``` On master, it's from 34s to the 2.7s above. r? compiler-errors just as a cc, as they said they might open the same PR later Opening as draft to do a perf run to see `deeply-nested-multi` (which should be fixed on the perf server now), and validate bootstrap times.

cache type sizes in type-size limit visitor This is rust-lang#125507 (comment) as lcnr can't open the PR now. Locally it reduces the `itertools` regression by quite a bit, "only 50%" compared to nightly. ```console Benchmark 1: cargo stage1 build --release Time (mean ± σ): 2.721 s ± 0.009 s [User: 2.446 s, System: 0.325 s] Range (min … max): 2.710 s … 2.738 s 10 runs Benchmark 2: cargo nightly build --release Time (mean ± σ): 1.784 s ± 0.005 s [User: 1.540 s, System: 0.279 s] Range (min … max): 1.778 s … 1.792 s 10 runs Summary cargo nightly build --release ran 1.52 ± 0.01 times faster than cargo stage1 build --release ``` On master, it's from 34s to the 2.7s above. r? compiler-errors just as a cc, as they said they might open the same PR later Opening as draft to do a perf run to see `deeply-nested-multi` fixed on the perf server (the type length has been bumped), and validate bootstrap times.

kornelski · 2024-07-04T17:15:49Z

This has broken real-world code for me (hard compile error, not just performance). Here's a minimized version:

use itertools::Itertools;

pub fn blah() {
    let _ = "".split("")
        .flat_map(|l| l.split(""))
        .flat_map(|l| l.split(""))
        .flat_map(|l| l.split(""))
        .flat_map(|l| l.split(""))
        .flat_map(|l| l.split(""))
        .flat_map(|l| l.split(""))
        .join("");
}

rust/library/core/src/iter/adapters/flatten.rs:653:9
|
653 | self.iter_try_fold(init, flatten(fold))
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: consider adding a #![type_length_limit="30043568"] attribute to your crate

rustc 1.81.0-nightly (aa1d4f6 2024-07-03)

lcnr · 2024-07-04T17:36:15Z

related to Prevent exponentially large type sizes in tuple_combinations rust-itertools/itertools#945

Itertools ends up with very large closure types, so this fels unsurprising and intended (as these large closures significantly degrade performance during canonicalization and can easily result in defacto hangs, especially with the new solver).

I hope you're able to patch the affected crate and increase its type length limit. Alternatively it may be worth it to patch itertools to outline the relevant closure here as well, similar to the PR mentioned aboe

cache type sizes in type-size limit visitor This is basically rust-lang#125507 (comment) as lcnr can't open the PR now. Locally it reduces the `itertools` regression by quite a bit, to "only 50%" compared to nightly (that includes overhead from the local lack of artifact post-processing, and is just a data point to compare to the 10-20x timings without the cache). ```console Benchmark 1: cargo stage1 build --release Time (mean ± σ): 2.721 s ± 0.009 s [User: 2.446 s, System: 0.325 s] Range (min … max): 2.710 s … 2.738 s 10 runs Benchmark 2: cargo nightly build --release Time (mean ± σ): 1.784 s ± 0.005 s [User: 1.540 s, System: 0.279 s] Range (min … max): 1.778 s … 1.792 s 10 runs Summary cargo nightly build --release ran 1.52 ± 0.01 times faster than cargo stage1 build --release ``` On master, it's from 34s to the 2.7s above. r? compiler-errors

kornelski · 2024-07-04T23:14:15Z

Ok, eventually it compiled, but I had to set max type length to 11GB (this repro function is part of another iterator…)

super deep stack trace

<hundreds omitted>
_RNvNtCs7ECJq7gLGVa_18rustc_monomorphize9collector17collect_items_rec
_RNvNtCs7ECJq7gLGVa_18rustc_monomorphize9collector17collect_items_rec
_RNvNtCs7ECJq7gLGVa_18rustc_monomorphize9collector17collect_items_rec
 _RNvNtCs7ECJq7gLGVa_18rustc_monomorphize9collector17collect_items_rec
  _RNvNtCs7ECJq7gLGVa_18rustc_monomorphize9collector17collect_items_rec
   _RNvNtCs7ECJq7gLGVa_18rustc_monomorphize9collector25collect_items_of_instance
    _RNvXs0_NtCs7ECJq7gLGVa_18rustc_monomorphize9collectorNtB5_16MirUsedCollectorNtNtNtCs6voQ6brMM63_12rustc_middle3mir5visit7Visitor16visit_terminator
     _RNvMs2_NtNtCs6voQ6brMM63_12rustc_middle2ty8instanceNtB5_8Instance14expect_resolve
      _RNvMs2_NtNtCs6voQ6brMM63_12rustc_middle2ty8instanceNtB5_8Instance11try_resolve
       _RINvXsp_NtNtCs6voQ6brMM63_12rustc_middle2ty16structural_implsNtB8_2TyINtNtCscfpqVFAc5KA_13rustc_type_ir5visit18TypeSuperVisitableNtNtB8_7context6TyCtxtE16super_visit_withNtNvNtB8_8instance11type_length7VisitorEBa_
        _RINvXsp_NtNtCs6voQ6brMM63_12rustc_middle2ty16structural_implsNtB8_2TyINtNtCscfpqVFAc5KA_13rustc_type_ir5visit18TypeSuperVisitableNtNtB8_7context6TyCtxtE16super_visit_withNtNvNtB8_8instance11type_length7VisitorEBa_
         _RINvXsp_NtNtCs6voQ6brMM63_12rustc_middle2ty16structural_implsNtB8_2TyINtNtCscfpqVFAc5KA_13rustc_type_ir5visit18TypeSuperVisitableNtNtB8_7context6TyCtxtE16super_visit_withNtNvNtB8_8instance11type_length7VisitorEBa_
          _RINvXsp_NtNtCs6voQ6brMM63_12rustc_middle2ty16structural_implsNtB8_2TyINtNtCscfpqVFAc5KA_13rustc_type_ir5visit18TypeSuperVisitableNtNtB8_7context6TyCtxtE16super_visit_withNtNvNtB8_8instance11type_length7VisitorEBa_
           _RINvXsp_NtNtCs6voQ6brMM63_12rustc_middle2ty16structural_implsNtB8_2TyINtNtCscfpqVFAc5KA_13rustc_type_ir5visit18TypeSuperVisitableNtNtB8_7context6TyCtxtE16super_visit_withNtNvNtB8_8instance11type_length7VisitorEBa_

cache type sizes in type-size limit visitor This is basically rust-lang/rust#125507 (comment) as lcnr can't open the PR now. Locally it reduces the `itertools` regression by quite a bit, to "only 50%" compared to nightly (that includes overhead from the local lack of artifact post-processing, and is just a data point to compare to the 10-20x timings without the cache). ```console Benchmark 1: cargo stage1 build --release Time (mean ± σ): 2.721 s ± 0.009 s [User: 2.446 s, System: 0.325 s] Range (min … max): 2.710 s … 2.738 s 10 runs Benchmark 2: cargo nightly build --release Time (mean ± σ): 1.784 s ± 0.005 s [User: 1.540 s, System: 0.279 s] Range (min … max): 1.778 s … 1.792 s 10 runs Summary cargo nightly build --release ran 1.52 ± 0.01 times faster than cargo stage1 build --release ``` On master, it's from 34s to the 2.7s above. r? compiler-errors

saethlin · 2024-07-06T23:41:02Z

The attribute required to make the code in #127346 compile is quite silly.

#![type_length_limit = "30491060267835378"]

Given that value is just over 2 << 53, I think we might have a deeper problem here. The type length limit is stored in a usize which means computing that type length will overflow on a 32-bit system, and we are getting disturbingly close to overflowing a 64-bit integer in Real Code. Peak memory usage on my system from building this crate is 1.5 GB. Given that we have a type length which is many factors of 2 beyond the memory usage of the entire compiler, does anyone think that indicates some kind of flaw in the reasoning that leads to the type length calculation? I've read over the code and it looks sensible to me; the only thing I can think of is that could produce this kind of blowup is many uses of the same interned Ty, but still... my intuition says that alone can't get us to 2 << 53.

Here's the implementation:

rust/compiler/rustc_middle/src/ty/instance.rs

Lines 391 to 422 in ed7e35f

    
           fn type_length<'tcx>(item: impl TypeVisitable<TyCtxt<'tcx>>) -> usize { 
        
               struct Visitor<'tcx> { 
        
                   type_length: usize, 
        
                   cache: FxHashMap<Ty<'tcx>, usize>, 
        
               } 
        
               impl<'tcx> TypeVisitor<TyCtxt<'tcx>> for Visitor<'tcx> { 
        
                   fn visit_ty(&mut self, t: Ty<'tcx>) { 
        
                       if let Some(&value) = self.cache.get(&t) { 
        
                           self.type_length  = value; 
        
                           return; 
        
                       } 
        
                       let prev = self.type_length; 
        
                       self.type_length  = 1; 
        
                       t.super_visit_with(self); 
        
                       // We don't try to use the cache if the type is fairly small. 
        
                       if self.type_length > 16 { 
        
                           self.cache.insert(t, self.type_length - prev); 
        
                       } 
        
                   } 
        
                   fn visit_const(&mut self, ct: ty::Const<'tcx>) { 
        
                       self.type_length  = 1; 
        
                       ct.super_visit_with(self); 
        
                   } 
        
               } 
        
               let mut visitor = Visitor { type_length: 0, cache: Default::default() }; 
        
               item.visit_with(&mut visitor); 
        
               visitor.type_length 
        
           }

Am I missing something obvious?

jackh726 · 2024-07-07T00:02:49Z

This seems to be causing problems for people. We should consider reverting this as we assess the impact and correctness.

This crate seems to have been broken by rust-lang/rust#125507, which re-introduces a type length limit check that wax already exceeded.

RossSmyth · 2024-07-08T14:00:21Z

The Helix editor no longer compiles on the latest nightly (154fdac39 2024-07-07). I believe it is because of this PR

Kobzol · 2024-07-09T19:56:54Z

This PR heavily regressed a stress test that contains very deeply nested types, but this perf. regression has since been fixed in #127288. Regarding the performance regression itself, I consider it to be resolved.

@rustbot label: perf-regression-triaged

Noratrieb · 2024-07-10T16:56:16Z

@saethlin having 53 level nested 2-element tuples is enough to reach 2<<53. That's just 53 distinct types, which, thanks to caching, is easily processed by the rest of the compiler.

edit: this appears to not be that simple from my testing, such nested tuples do OOM the compiler :3

…=lcnr Re-implement a type-size based limit r? lcnr This PR reintroduces the type length limit added in rust-lang#37789, which was accidentally made practically useless by the caching changes to `Ty::walk` in rust-lang#72412, which caused the `walk` function to no longer walk over identical elements. Hitting this length limit is not fatal unless we are in codegen -- so it shouldn't affect passes like the mir inliner which creates potentially very large types (which we observed, for example, when the new trait solver compiles `itertools` in `--release` mode). This also increases the type length limit from `1048576 == 2 ** 20` to `2 ** 24`, which covers all of the code that can be reached with craterbot-check. Individual crates can increase the length limit further if desired. Perf regression is mild and I think we should accept it -- reinstating this limit is important for the new trait solver and to make sure we don't accidentally hit more type-size related regressions in the future. Fixes rust-lang#125460

Upgrade toolchain to 7/12 Relevant PRs: rust-lang/rust#127176 and rust-lang/rust#125507 Resolves #3319 By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.

…, r=jackh726 Gate the type length limit check behind a nightly flag Effectively disables the type length limit by introducing a `-Zenforce-type-length-limit` which defaults to **`false`**, since making the length limit actually be enforced ended up having a worse fallout than expected. We still keep the code around, but the type length limit attr is now a noop (except for its usage in some diagnostics code?). r? `@lcnr` -- up to you to decide what team consensus we need here since this reverses an FCP decision. Reopens rust-lang#125460 (if we decide to reopen it or keep it closed) Effectively reverses the decision FCP'd in rust-lang#125507 Closes rust-lang#127346

This MR contains the following updates: | Package | Update | Change | |---|---|---| | [rust](https://github.com/rust-lang/rust) | minor | `1.80.1` -> `1.81.0` | MR created with the help of [el-capitano/tools/renovate-bot](https://gitlab.com/el-capitano/tools/renovate-bot). **Proposed changes to behavior should be submitted there as MRs.** --- ### Release Notes <details> <summary>rust-lang/rust (rust)</summary> ### [`v1.81.0`](https://github.com/rust-lang/rust/blob/HEAD/RELEASES.md#Version-1810-2024-09-05) [Compare Source](rust-lang/rust@1.80.1...1.81.0) \========================== <a id="1.81.0-Language"></a> ## Language - [Abort on uncaught panics in `extern "C"` functions.](rust-lang/rust#116088) - [Fix ambiguous cases of multiple `&` in elided self lifetimes.](rust-lang/rust#117967) - [Stabilize `#[expect]` for lints (RFC 2383),](rust-lang/rust#120924) like `#[allow]` with a warning if the lint is *not* fulfilled. - [Change method resolution to constrain hidden types instead of rejecting method candidates.](rust-lang/rust#123962) - [Bump `elided_lifetimes_in_associated_constant` to deny.](rust-lang/rust#124211) - [`offset_from`: always allow pointers to point to the same address.](rust-lang/rust#124921) - [Allow constraining opaque types during subtyping in the trait system.](rust-lang/rust#125447) - [Allow constraining opaque types during various unsizing casts.](rust-lang/rust#125610) - [Deny keyword lifetimes pre-expansion.](rust-lang/rust#126762) <a id="1.81.0-Compiler"></a> ## Compiler - [Make casts of pointers to trait objects stricter.](rust-lang/rust#120248) - [Check alias args for well-formedness even if they have escaping bound vars.](rust-lang/rust#123737) - [Deprecate no-op codegen option `-Cinline-threshold=...`.](rust-lang/rust#124712) - [Re-implement a type-size based limit.](rust-lang/rust#125507) - [Properly account for alignment in `transmute` size checks.](rust-lang/rust#125740) - [Remove the `box_pointers` lint.](rust-lang/rust#126018) - [Ensure the interpreter checks bool/char for validity when they are used in a cast.](rust-lang/rust#126265) - [Improve coverage instrumentation for functions containing nested items.](rust-lang/rust#127199) - Target changes: - [Add Tier 3 `no_std` Xtensa targets:](rust-lang/rust#125141) `xtensa-esp32-none-elf`, `xtensa-esp32s2-none-elf`, `xtensa-esp32s3-none-elf` - [Add Tier 3 `std` Xtensa targets:](rust-lang/rust#126380) `xtensa-esp32-espidf`, `xtensa-esp32s2-espidf`, `xtensa-esp32s3-espidf` - [Add Tier 3 i686 Redox OS target:](rust-lang/rust#126192) `i686-unknown-redox` - [Promote `arm64ec-pc-windows-msvc` to Tier 2.](rust-lang/rust#126039) - [Promote `loongarch64-unknown-linux-musl` to Tier 2 with host tools.](rust-lang/rust#126298) - [Enable full tools and profiler for LoongArch Linux targets.](rust-lang/rust#127078) - [Unconditionally warn on usage of `wasm32-wasi`.](rust-lang/rust#126662) (see compatibility note below) - Refer to Rust's \[platform support page]\[platform-support-doc] for more information on Rust's tiered platform support. <a id="1.81.0-Libraries"></a> ## Libraries - [Split core's `PanicInfo` and std's `PanicInfo`.](rust-lang/rust#115974) (see compatibility note below) - [Generalize `{Rc,Arc}::make_mut()` to unsized types.](rust-lang/rust#116113) - [Replace sort implementations with stable `driftsort` and unstable `ipnsort`.](rust-lang/rust#124032) All `slice::sort*` and `slice::select_nth*` methods are expected to see significant performance improvements. See the [research project](https://github.com/Voultapher/sort-research-rs) for more details. - [Document behavior of `create_dir_all` with respect to empty paths.](rust-lang/rust#125112) - [Fix interleaved output in the default panic hook when multiple threads panic simultaneously.](rust-lang/rust#127397) <a id="1.81.0-Stabilized-APIs"></a> ## Stabilized APIs - [`core::error`](https://doc.rust-lang.org/stable/core/error/index.html) - [`hint::assert_unchecked`](https://doc.rust-lang.org/stable/core/hint/fn.assert_unchecked.html) - [`fs::exists`](https://doc.rust-lang.org/stable/std/fs/fn.exists.html) - [`AtomicBool::fetch_not`](https://doc.rust-lang.org/stable/core/sync/atomic/struct.AtomicBool.html#method.fetch_not) - [`Duration::abs_diff`](https://doc.rust-lang.org/stable/core/time/struct.Duration.html#method.abs_diff) - [`IoSlice::advance`](https://doc.rust-lang.org/stable/std/io/struct.IoSlice.html#method.advance) - [`IoSlice::advance_slices`](https://doc.rust-lang.org/stable/std/io/struct.IoSlice.html#method.advance_slices) - [`IoSliceMut::advance`](https://doc.rust-lang.org/stable/std/io/struct.IoSliceMut.html#method.advance) - [`IoSliceMut::advance_slices`](https://doc.rust-lang.org/stable/std/io/struct.IoSliceMut.html#method.advance_slices) - [`PanicHookInfo`](https://doc.rust-lang.org/stable/std/panic/struct.PanicHookInfo.html) - [`PanicInfo::message`](https://doc.rust-lang.org/stable/core/panic/struct.PanicInfo.html#method.message) - [`PanicMessage`](https://doc.rust-lang.org/stable/core/panic/struct.PanicMessage.html) These APIs are now stable in const contexts: - [`char::from_u32_unchecked`](https://doc.rust-lang.org/stable/core/char/fn.from_u32\_unchecked.html) (function) - [`char::from_u32_unchecked`](https://doc.rust-lang.org/stable/core/primitive.char.html#method.from_u32\_unchecked) (method) - [`CStr::count_bytes`](https://doc.rust-lang.org/stable/core/ffi/c_str/struct.CStr.html#method.count_bytes) - [`CStr::from_ptr`](https://doc.rust-lang.org/stable/core/ffi/c_str/struct.CStr.html#method.from_ptr) <a id="1.81.0-Cargo"></a> ## Cargo - [Generated `.cargo_vcs_info.json` is always included, even when `--allow-dirty` is passed.](rust-lang/cargo#13960) - [Disallow `package.license-file` and `package.readme` pointing to non-existent files during packaging.](rust-lang/cargo#13921) - [Disallow passing `--release`/`--debug` flag along with the `--profile` flag.](rust-lang/cargo#13971) - [Remove `lib.plugin` key support in `Cargo.toml`. Rust plugin support has been deprecated for four years and was removed in 1.75.0.](rust-lang/cargo#13902) <a id="1.81.0-Compatibility-Notes"></a> ## Compatibility Notes - Usage of the `wasm32-wasi` target will now issue a compiler warning and request users switch to the `wasm32-wasip1` target instead. Both targets are the same, `wasm32-wasi` is only being renamed, and this [change to the WASI target](https://blog.rust-lang.org/2024/04/09/updates-to-rusts-wasi-targets.html) is being done to enable removing `wasm32-wasi` in January 2025. - We have renamed `std::panic::PanicInfo` to `std::panic::PanicHookInfo`. The old name will continue to work as an alias, but will result in a deprecation warning starting in Rust 1.82.0. `core::panic::PanicInfo` will remain unchanged, however, as this is now a *different type*. The reason is that these types have different roles: `std::panic::PanicHookInfo` is the argument to the [panic hook](https://doc.rust-lang.org/stable/std/panic/fn.set_hook.html) in std context (where panics can have an arbitrary payload), while `core::panic::PanicInfo` is the argument to the [`#[panic_handler]`](https://doc.rust-lang.org/nomicon/panic-handler.html) in no_std context (where panics always carry a formatted *message*). Separating these types allows us to add more useful methods to these types, such as `std::panic::PanicHookInfo::payload_as_str()` and `core::panic::PanicInfo::message()`. - The new sort implementations may panic if a type's implementation of [`Ord`](https://doc.rust-lang.org/std/cmp/trait.Ord.html) (or the given comparison function) does not implement a [total order](https://en.wikipedia.org/wiki/Total_order) as the trait requires. `Ord`'s supertraits (`PartialOrd`, `Eq`, and `PartialEq`) must also be consistent. The previous implementations would not "notice" any problem, but the new implementations have a good chance of detecting inconsistencies, throwing a panic rather than returning knowingly unsorted data. - [In very rare cases, a change in the internal evaluation order of the trait solver may result in new fatal overflow errors.](rust-lang/rust#126128) <a id="1.81.0-Internal-Changes"></a> ## Internal Changes These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools. - [Add a Rust-for Linux `auto` CI job to check kernel builds.](rust-lang/rust#125209) </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this MR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this MR, check this box --- This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).

Pkgsrc changes: * Adapt patches, apply to new vendored crates where needed. * Back-port rust pull request 130110, "make dist vendoring configurable" * Disable "dist vendoring", otherwise cargo would try to access the network during the build phase. Upstream changes: Version 1.81.0 (2024-09-05) ========================== Language -------- - [Abort on uncaught panics in `extern "C"` functions.] (rust-lang/rust#116088) - [Fix ambiguous cases of multiple `&` in elided self lifetimes.] (rust-lang/rust#117967) - [Stabilize `#[expect]` for lints (RFC 2383),] (rust-lang/rust#120924) like `#[allow]` with a warning if the lint is _not_ fulfilled. - [Change method resolution to constrain hidden types instead of rejecting method candidates.] (rust-lang/rust#123962) - [Bump `elided_lifetimes_in_associated_constant` to deny.] (rust-lang/rust#124211) - [`offset_from`: always allow pointers to point to the same address.] (rust-lang/rust#124921) - [Allow constraining opaque types during subtyping in the trait system.] (rust-lang/rust#125447) - [Allow constraining opaque types during various unsizing casts.] (rust-lang/rust#125610) - [Deny keyword lifetimes pre-expansion.] (rust-lang/rust#126762) Compiler -------- - [Make casts of pointers to trait objects stricter.] (rust-lang/rust#120248) - [Check alias args for well-formedness even if they have escaping bound vars.] (rust-lang/rust#123737) - [Deprecate no-op codegen option `-Cinline-threshold=...`.] (rust-lang/rust#124712) - [Re-implement a type-size based limit.] (rust-lang/rust#125507) - [Properly account for alignment in `transmute` size checks.] (rust-lang/rust#125740) - [Remove the `box_pointers` lint.] (rust-lang/rust#126018) - [Ensure the interpreter checks bool/char for validity when they are used in a cast.] (rust-lang/rust#126265) - [Improve coverage instrumentation for functions containing nested items.] (rust-lang/rust#127199) - Target changes: - [Add Tier 3 `no_std` Xtensa targets:] (rust-lang/rust#125141) `xtensa-esp32-none-elf`, `xtensa-esp32s2-none-elf`, `xtensa-esp32s3-none-elf` - [Add Tier 3 `std` Xtensa targets:] (rust-lang/rust#126380) `xtensa-esp32-espidf`, `xtensa-esp32s2-espidf`, `xtensa-esp32s3-espidf` - [Add Tier 3 i686 Redox OS target:] (rust-lang/rust#126192) `i686-unknown-redox` - [Promote `arm64ec-pc-windows-msvc` to Tier 2.] (rust-lang/rust#126039) - [Promote `wasm32-wasip2` to Tier 2.] (rust-lang/rust#126967) - [Promote `loongarch64-unknown-linux-musl` to Tier 2 with host tools.] (rust-lang/rust#126298) - [Enable full tools and profiler for LoongArch Linux targets.] (rust-lang/rust#127078) - [Unconditionally warn on usage of `wasm32-wasi`.] (rust-lang/rust#126662) (see compatibility note below) - Refer to Rust's [platform support page][platform-support-doc] for more information on Rust's tiered platform support. Libraries --------- - [Split core's `PanicInfo` and std's `PanicInfo`.] (rust-lang/rust#115974) (see compatibility note below) - [Generalize `{Rc,Arc}::make_mut()` to unsized types.] (rust-lang/rust#116113) - [Replace sort implementations with stable `driftsort` and unstable `ipnsort`.] (rust-lang/rust#124032) All `slice::sort*` and `slice::select_nth*` methods are expected to see significant performance improvements. See the [research project] (https://github.com/Voultapher/sort-research-rs) for more details. - [Document behavior of `create_dir_all` with respect to empty paths.] (rust-lang/rust#125112) - [Fix interleaved output in the default panic hook when multiple threads panic simultaneously.] (rust-lang/rust#127397) - Fix `Command`'s batch files argument escaping not working when file name has trailing whitespace or periods (CVE-2024-43402). Stabilized APIs --------------- - [`core::error`] (https://doc.rust-lang.org/stable/core/error/index.html) - [`hint::assert_unchecked`] (https://doc.rust-lang.org/stable/core/hint/fn.assert_unchecked.html) - [`fs::exists`] (https://doc.rust-lang.org/stable/std/fs/fn.exists.html) - [`AtomicBool::fetch_not`] (https://doc.rust-lang.org/stable/core/sync/atomic/struct.AtomicBool.html#method.fetch_not) - [`Duration::abs_diff`] (https://doc.rust-lang.org/stable/core/time/struct.Duration.html#method.abs_diff) - [`IoSlice::advance`] (https://doc.rust-lang.org/stable/std/io/struct.IoSlice.html#method.advance) - [`IoSlice::advance_slices`] (https://doc.rust-lang.org/stable/std/io/struct.IoSlice.html#method.advance_slices) - [`IoSliceMut::advance`] (https://doc.rust-lang.org/stable/std/io/struct.IoSliceMut.html#method.advance) - [`IoSliceMut::advance_slices`] (https://doc.rust-lang.org/stable/std/io/struct.IoSliceMut.html#method.advance_slices) - [`PanicHookInfo`] (https://doc.rust-lang.org/stable/std/panic/struct.PanicHookInfo.html) - [`PanicInfo::message`] (https://doc.rust-lang.org/stable/core/panic/struct.PanicInfo.html#method.message) - [`PanicMessage`] (https://doc.rust-lang.org/stable/core/panic/struct.PanicMessage.html) These APIs are now stable in const contexts: - [`char::from_u32_unchecked`] (https://doc.rust-lang.org/stable/core/char/fn.from_u32_unchecked.html) (function) - [`char::from_u32_unchecked`] (https://doc.rust-lang.org/stable/core/primitive.char.html#method.from_u32_unchecked) (method) - [`CStr::count_bytes`] (https://doc.rust-lang.org/stable/core/ffi/c_str/struct.CStr.html#method.count_bytes) - [`CStr::from_ptr`] (https://doc.rust-lang.org/stable/core/ffi/c_str/struct.CStr.html#method.from_ptr) Cargo ----- - [Generated `.cargo_vcs_info.json` is always included, even when `--allow-dirty` is passed.] (rust-lang/cargo#13960) - [Disallow `package.license-file` and `package.readme` pointing to non-existent files during packaging.] (rust-lang/cargo#13921) - [Disallow passing `--release`/`--debug` flag along with the `--profile` flag.] (rust-lang/cargo#13971) - [Remove `lib.plugin` key support in `Cargo.toml`. Rust plugin support has been deprecated for four years and was removed in 1.75.0.] (rust-lang/cargo#13902) Compatibility Notes ------------------- * Usage of the `wasm32-wasi` target will now issue a compiler warning and request users switch to the `wasm32-wasip1` target instead. Both targets are the same, `wasm32-wasi` is only being renamed, and this [change to the WASI target] (https://blog.rust-lang.org/2024/04/09/updates-to-rusts-wasi-targets.html) is being done to enable removing `wasm32-wasi` in January 2025. * We have renamed `std::panic::PanicInfo` to `std::panic::PanicHookInfo`. The old name will continue to work as an alias, but will result in a deprecation warning starting in Rust 1.82.0. `core::panic::PanicInfo` will remain unchanged, however, as this is now a *different type*. The reason is that these types have different roles: `std::panic::PanicHookInfo` is the argument to the [panic hook](https://doc.rust-lang.org/stable/std/panic/fn.set_hook.html) in std context (where panics can have an arbitrary payload), while `core::panic::PanicInfo` is the argument to the [`#[panic_handler]`](https://doc.rust-lang.org/nomicon/panic-handler.html) in no_std context (where panics always carry a formatted *message*). Separating these types allows us to add more useful methods to these types, such as `std::panic::PanicHookInfo::payload_as_str()` and `core::panic::PanicInfo::message()`. * The new sort implementations may panic if a type's implementation of [`Ord`](https://doc.rust-lang.org/std/cmp/trait.Ord.html) (or the given comparison function) does not implement a [total order](https://en.wikipedia.org/wiki/Total_order) as the trait requires. `Ord`'s supertraits (`PartialOrd`, `Eq`, and `PartialEq`) must also be consistent. The previous implementations would not "notice" any problem, but the new implementations have a good chance of detecting inconsistencies, throwing a panic rather than returning knowingly unsorted data. * [In very rare cases, a change in the internal evaluation order of the trait solver may result in new fatal overflow errors.] (rust-lang/rust#126128) Internal Changes ---------------- These changes do not affect any public interfaces of Rust, but they represent significant improvements to the performance or internals of rustc and related tools. - [Add a Rust-for Linux `auto` CI job to check kernel builds.] (rust-lang/rust#125209)

rustbot assigned lcnr May 24, 2024

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels May 24, 2024