Rollup of 8 pull requests

[JohnTitor]

Successful merges:

• Error code cleanup and enforce checks #86137 (Error code cleanup and enforce checks)
• Add documentation for various THIR structs #86296 (Add documentation for various THIR structs)
• Document associativity of iterator folds. #86415 (Document associativity of iterator folds.)
• Support lowercase error codes in --explain #86533 (Support lowercase error codes in --explain)
• Edition 2021 enables disjoint capture #86536 (Edition 2021 enables disjoint capture)
• Update cargo #86560 (Update cargo)
• chore(rustdoc): Remove unused impl block #86561 (chore(rustdoc): Remove unused impl block)
• Use use_verbose for mir::Constant #86566 (Use use_verbose for mir::Constant)

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

[JohnTitor]

@bors r+ p=8 rollup=never

[bors]

📌 Commit 64c9712 has been approved by JohnTitor

[bors]

⌛ Testing commit 64c9712 with merge 964a81e...

[bors]

☀️ Test successful - checks-actions
Approved by: JohnTitor
Pushing 964a81e to master...

[rylev]

This rollup led to moderate regressions in deeply-nested-async and some lesser ones in a couple of other benchmarks. This rollup was largely documentation and tooling related. The only real changes in code were in MIR pretty printing and checking spans to see if Rust 2021 closure capturing should be used. Both seem rather benign. However, given the performance regression is async code (which may take more advantage of closures), perhaps the closure capture change should be investigated first.

cc @arora-aman @nikomatsakis

As part of the performance triage process, I'm marking this as a performance regression. If you believe this performance regression to be justifiable or once you have an issue or PR that addresses this regression, please mark this PR with the label perf-regression-triaged.

@rustbot label +perf-regression

[arora-aman]

@rylev @nikomatsakis I did a perf run with all code relating to checking edition wrt disjoint capture removed. There doesn't seem to be any significant benefit of doing so for any of the benchmarks. Only bootstrap seems to be affected.

Details here: #86967 (comment)

I don't think it's 2229 being enabled by default that caused this regression

[Mark-Simulacrum]

cachegrind diff for deeply-nested-async Check Full, on the published artifacts, shows:

 82,573,070 (122.9%)  ???:core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &mut F>::call_once
-13,762,254 (-20.5%)  ???:<smallvec::SmallVec<A> as core::iter::traits::collect::Extend<<A as smallvec::Array>::Item>>::extend
 -1,592,100 (-2.37%)  ???:hashbrown::map::RawEntryBuilderMut<K,V,S,A>::from_hash

This is not particularly revealing, unfortunately.

The externs Debug IncrFull benchmark also showed a regression, but its results don't point to anything obvious:

18,087,258 (97.55%)  ???:rustc_middle::dep_graph::<impl rustc_query_system::dep_graph::DepKind for rustc_middle::dep_graph::dep_node::DepKind>::read_deps
   216,000 ( 1.17%)  ???:<rustc_expand::placeholders::PlaceholderExpander as rustc_ast::mut_visit::MutVisitor>::flat_map_param
   180,000 ( 0.97%)  ???:rustc_lexer::<impl rustc_lexer::cursor::Cursor>::advance_token
  -158,998 (-0.86%)  ???:<alloc::vec::Vec<T> as rustc_data_structures::map_in_place::MapInPlace<T>>::flat_map_in_place
   135,090 ( 0.73%)  ???:core::ptr::drop_in_place<rustc_ast::ast::Path>
  -108,072 (-0.58%)  ???:core::ptr::drop_in_place<rustc_ast::ast::Attribute>
   104,230 ( 0.56%)  ???:core::ptr::drop_in_place<alloc::vec::Vec<rustc_ast::ast::PathSegment>>
    96,000 ( 0.52%)  ???:rustc_hir::intravisit::walk_qpath
   -89,575 (-0.48%)  ???:<alloc::vec::Vec<T,A> as core::ops::drop::Drop>::drop
    33,227 ( 0.18%)  ???:<hashbrown::raw::RawIterHash<T,A> as core::iter::traits::iterator::Iterator>::next
    25,021 ( 0.13%)  ???:hashbrown::map::HashMap<K,V,S,A>::insert
    20,489 ( 0.11%)  ???:hashbrown::map::RawEntryBuilder<K,V,S,A>::from_key_hashed_nocheck

Ultimately these results don't point to something obvious -- it seems plausible that the changes are due to a number of factors. The added code in the executable might be hurting PGO, for example, which may be causing this. Local builds + benchmarks aren't able to reproduce any regression (rather typically show very small improvements, likely lost in the noise) as a result of this PR, though those are done without PGO.

So I'm going to say that this is small enough that I'm OK marking as triaged as-is. @rustbot label +perf-regression-triaged