Split core::slice to smaller mods

[tesuji]

Unfortunately the #[lang = "slice"] is too big (3003 lines), I cannot split it further.

Note for reviewer:

• I split to multiple commits for easier reviewing, but I could git squash them all to one if requested.
• Recommend pulling this change locally and using advanced git diff viewer or this command:

  git show --reverse --color-moved=dimmed-zebra master..
  

---

I split core/slice/mod.rs to these modules:

• ascii: For operations on [u8].
• cmp: For comparison operations on [T], like PartialEq and SliceContains impl.
• index: For indexing operations like Index/IndexMut and SliceIndex.
• iter: For Iterator definitions and implementation on [T].
  • macros: For iterator! and forward_iterator! macros.
• raw: For free function to create &[T] or &mut [T] from pointer + length or a reference.

The heapsort wrapper in mod.rs is removed in favor of reexport from sort::heapsort.

[tesuji]

cc #60302
r? @Mark-Simulacrum for review or reassignment
@rustbot modify labels: +S-waiting-on-review

[bors]

☔ The latest upstream changes (presumably #75207) made this pull request unmergeable. Please resolve the merge conflicts.

[pickfire]

Interesting, I didn't know about --color-moved=dimmed-zebra.

[bors]

☔ The latest upstream changes (presumably #76540) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

[tesuji]

Rebased.

[tesuji]

r? @lcnr

[bors]

☔ The latest upstream changes (presumably #75021) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

[tesuji]

Rebased.

[bors]

☔ The latest upstream changes (presumably #76678) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

[tesuji]

Rebased.

[tesuji]

Rebasing merge conflicts in these pull requests is kinda painful without being reviewed.
I have to make sure the rebase don't miss any details.
I am going to close these PRs and tell the associated issue #60302 that it is a won't fix issue.

[lcnr]

will try to review this today, sorry for being silent this weekend

[bors]

📌 Commit 6655ad7 has been approved by lcnr

[bors]

⌛ Testing commit 6655ad7 with merge 4aa7dc2038d4fe5064c83fe5737e3b7c0d086829...

[bors]

💔 Test failed - checks-actions

[lcnr]

I think you have to update

rust/src/tools/clippy/clippy_lints/src/utils/paths.rs

Line 109 in 6cae281

pubconstSLICE_ITER:[&str;3] = ["core","slice","Iter"];

to fix this.

[tesuji]

Oh, my fool. Thought that a spurious failure in the previous error.
Filed rust-lang/rust-clippy#6047 to improve the situation.

[lcnr]

@bors r+ rollup=never

[bors]

📌 Commit c65050d has been approved by lcnr

[bors]

⌛ Testing commit c65050d with merge 4c1966f...

[bors]

☀️ Test successful - checks-actions, checks-azure
Approved by: lcnr
Pushing 4c1966f to master...

[ecstatic-morse]

Hi! This PR showed up in the weekly perf triage report. It resulted in a moderate improvement in instruction counts (up to -1.9% on full builds of html5ever-opt). However, most other benchmarks regressed very slightly.

I've observed some other module splitting PRs that have unexpected effects on performance. I wonder why that is? In any case, I don't think there's anything to be done here. Thanks @lzutao.

[bjorn3]

Every module contributes one codegen unit (before cgu merging). By splitting a module you get more codegen units. This can have an effect on performance.