Rollup of 10 pull requests

[JohnTitor]

Successful merges:

• BTreeMap: remove into_slices and its unsafe block #74686 (BTreeMap: remove into_slices and its unsafe block)
• BTreeMap::drain_filter should not touch the root during iteration #74762 (BTreeMap::drain_filter should not touch the root during iteration)
• Clean up E0733 explanation #74781 (Clean up E0733 explanation)
• BTreeMap: define forget_type only when relevant #74874 (BTreeMap: define forget_type only when relevant)
• Make tests faster in Miri #74974 (Make tests faster in Miri)
• Update elasticlunr-rs and ammonia transitive deps #75010 (Update elasticlunr-rs and ammonia transitive deps)
• Replaced log with tracing crate #75041 (Replaced log with tracing crate)
• Clean up E0744 explanation #75044 (Clean up E0744 explanation)
• Rename rustc_middle::cstore::DepKind to CrateDepKind #75054 (Rename rustc_middle::cstore::DepKind to CrateDepKind)
• Avoid dumping rustc invocations to stdout #75057 (Avoid dumping rustc invocations to stdout)

Failed merges:

• Move bulk of BTreeMap::insert method down to new method on handle #74827 (Move bulk of BTreeMap::insert method down to new method on handle)

r? @ghost

[JohnTitor]

@rustbot modify labels: +rollup
@bors r+ rollup=never p=5

[bors]

📌 Commit 50f2b5d has been approved by JohnTitor

[bors]

⌛ Testing commit 50f2b5d with merge a99ae95...

[bors]

☀️ Test successful - checks-actions, checks-azure
Approved by: JohnTitor
Pushing a99ae95 to master...

[Mark-Simulacrum]

This was a slight performance regression, of up to 1%. Perhaps one of the BTree PRs are at fault? I recall there being some known regressions there.

[JohnTitor]

Hmm, I'm not familiar with that, cc @ssomers in case.

[ssomers]

#74762 is the only one that shows a penalty, benchmarking with stage 0. I.e.

benchcmp o o1 --threshold 5
 name                                           o ns/iter  o1 ns/iter  diff ns/iter  diff %  speedup
 btree::map::clone_fat_100_and_drain_all        172,930    155,862          -17,068  -9.87%   x 1.11
 btree::map::clone_fat_100_and_remove_all       173,350    218,235           44,885  25.89%   x 0.79
 btree::map::clone_fat_100_and_remove_half      118,970    138,497           19,527  16.41%   x 0.86
 btree::map::clone_fat_val_100_and_remove_all   81,776     96,849            15,073  18.43%   x 0.84
 btree::map::clone_fat_val_100_and_remove_half  57,137     64,924             7,787  13.63%   x 0.88
 btree::map::clone_slim_100_and_clear           2,258      2,137               -121  -5.36%   x 1.06
 btree::map::clone_slim_100_and_remove_all      4,873      5,172                299   6.14%   x 0.94
 btree::map::first_and_last_0                   30         32                     2   6.67%   x 0.94
 btree::map::insert_rand_100                    41         44                     3   7.32%   x 0.93
 btree::map::insert_rand_10_000                 41         45                     4   9.76%   x 0.91
 btree::map::insert_seq_10_000                  95         100                    5   5.26%   x 0.95
 btree::map::iter_0                             1,485      1,734                249  16.77%   x 0.86
 btree::set::is_subset_100_vs_10k               1,223      1,292                 69   5.64%   x 0.95

They're mostly benchmarks that keep changing their tune up and down whenever you touch some code, except the clone_fat tests, which are brand new. Looking closer and without threshold, all of the remove benchmarks are doing worse, and remove is the only genuine change in the PR. But amost all the drain_filter ones do better. I would think that the introduction of remove_kv_tracking to support drain_filter months ago would have had much more effect. I don't mind reverting the genuine change or all of it. It's not an ideal implementation for drain_filter anyway and I think by now I might be able to write one, without interfering with remove.

[JohnTitor]

@ssomers Thanks for investigating it!

@Mark-Simulacrum Is it worth to revert it and check perf run?

[ssomers]

#75182 may be a better thing to check the perf of