impl Pattern for char array

[camsteffen]

Closes #39511
Closes #86329

[rust-highfive]

r? @dtolnay

(rust-highfive has picked a reviewer for you, use r? to override)

[scottmcm]

This might be a silly question, but why for &[char; N] instead of for [char; N]?

[camsteffen]

Actually that's what I started with, but then I figured this is more flexible/performant for large arrays. Definitely open to discussion on that. Maybe add both?

[cuviper]

I think you do want the reference to solve those bugs where one intends to write a literal &[char] slice pattern, but it's really &[char; N].

[scottmcm]

I think both -- ['o', 'l'] for the simple case, and &[...] for the case cuviper mentions.

(I might just delegate both to the impl for slices, though, if there's an easy way to do that.)

[camsteffen]

Okay, added both. Unfortunately lifetimes force a lot of separate structs and impls to satisfy into_searcher.

[dtolnay]

@rust-lang/libs-api:
@rfcbot fcp merge

This PR adds impl<'a, const N: usize> Pattern<'a> for [char; N] and impl<'a, 'b, const N: usize> Pattern<'a> for &'b [char; N], which allows str::find and similar methods based on Pattern to work as:

"...".find([' ', '\r', '\n'])
// or:
"...".find(&[' ', '\r', '\n'])

whereas before, due to #39511, it would have had to be written as:

"...".find(&[' ', '\r', '\n'][..])

[rfcbot]

Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @yaahc

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[camsteffen]

Squashed a fixup commit

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

[camelid]

It looks like this PR just needs a final review now that FCP has finished.

[camelid]

Should relnotes be added since IIUC this is insta-stable (even though Pattern itself is not stable)?

[camsteffen]

@dtolnay you approved the changes in Github. Is that grounds to r=yoself?

[camelid]

(Adding relnotes since this is insta-stable.)

[joshtriplett]

@bors r+

[bors]

📌 Commit 28f7890 has been approved by joshtriplett

[bors]

⌛ Testing commit 28f7890 with merge c7e4740...

[bors]

☀️ Test successful - checks-actions
Approved by: joshtriplett
Pushing c7e4740 to master...

[rust-timer]

Finished benchmarking commit (c7e4740): comparison url.

Summary: This change led to small relevant regressions 😿 in compiler performance.

• Small regression in instruction counts (up to 0.6% on full builds of deeply-nested-async)

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please open an issue or create a new PR that fixes the regressions, add a comment linking to the newly created issue or PR, and then add the perf-regression-triaged label to this PR.

@rustbot label: +perf-regression

[pnkfelix]

visiting for triage.

The only benchmarks that regressed did so by a small amount, percentage wise 0.2-0.6%; the benchmarks that did regress in that fashion are deeply-nested-async, helloworld, unify-linearly.

I am surprised that this change caused even this minor regression, but I don't think its worth investing effort trying to figure out why, unless someone wants to take it on as a self-educating exercise.

@rustbot label: +perf-regression-triaged