Fix lookahead with None-delimited group

[Aaron1011]

Fixes #84162, a regression introduced by #82608.

[rust-highfive]

r? @estebank

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

[Aaron1011]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit eb7b1a1 with merge ce7729406a858c09fb39886aa783593f2f8d2d62...

[pickfire]

Suggested change

	let mut i = 0;
	let mut token = Token::dummy();
	while i < dist {
	token = cursor.next().0;
	if matches!(
	token.kind,
	token::OpenDelim(token::NoDelim) | token::CloseDelim(token::NoDelim)
	) {
	continue;
	}
	i += 1;
	}
	let mut token = Token::dummy();
	while dist > 0 {
	token = cursor.next().0;
	if !matches!(
	token.kind,
	token::OpenDelim(token::NoDelim) | token::CloseDelim(token::NoDelim)
	) {
	dist -= 1;
	}
	}

Will this be better?

[petrochenkov]

Looks less intuitive to me.

[bors]

☀️ Try build successful - checks-actions
Build commit: ce7729406a858c09fb39886aa783593f2f8d2d62 (ce7729406a858c09fb39886aa783593f2f8d2d62)

[rust-timer]

Queued ce7729406a858c09fb39886aa783593f2f8d2d62 with parent c18c0ad, future comparison URL.

[rust-timer]

Finished benchmarking try commit (ce7729406a858c09fb39886aa783593f2f8d2d62): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

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

[Aaron1011]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit c6d67f8 with merge 2cf9ebe7a46b277e9440ebc9a642932dc0a3f08c...

[bors]

☀️ Try build successful - checks-actions
Build commit: 2cf9ebe7a46b277e9440ebc9a642932dc0a3f08c (2cf9ebe7a46b277e9440ebc9a642932dc0a3f08c)

[rust-timer]

Queued 2cf9ebe7a46b277e9440ebc9a642932dc0a3f08c with parent d0695c9, future comparison URL.

[rust-timer]

Finished benchmarking try commit (2cf9ebe7a46b277e9440ebc9a642932dc0a3f08c): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

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

[Aaron1011]

Apparently, this is a small performance win on a few benchmarks.

r? @petrochenkov

[Mark-Simulacrum]

rustc_parse compilation has regressed 10%, which is above the usual noise on that measurement. Is that expected?

[Aaron1011]

@virtualritz: It should be possible for affected crate authors to request rebuilds by opening issues on https://github.com/rust-lang/docs.rs

[jethrogb]

@rustbot modify labels: +regression-from-stable-to-nightly

[jyn514]

@jethrogb this is tracked by #84162, we don't prioritize PRs usually.

[jethrogb]

Whoops, my bad, it's right there in the PR description.

[jyn514]

Whoops, my bad, it's right there in the PR description.

Only since a few minutes ago 😉 I edited it

[petrochenkov]

@bors r+

[bors]

📌 Commit c6d67f8 has been approved by petrochenkov

[jyn514]

@bors p=1 this is breaking a lot of crates

[bors]

⌛ Testing commit c6d67f8 with merge 16bf626...

[bors]

☀️ Test successful - checks-actions
Approved by: petrochenkov
Pushing 16bf626 to master...

[rylev]

@Aaron1011 @petrochenkov @Mark-Simulacrum Looks like the perf run performed after this was merged showed the same regressions in compilation of the same benchmarks as well as compilation of rustc_parse crate.

The compilation regressions in the benchmarks might be expected since this is strictly doing more work, but I wonder if we have an idea why this would regress compilation of the rustc_parse crate itself so much.

[Mark-Simulacrum]

I think I actually have a pretty good sense: that function likely gets duplicated a bunch of times, as it's generic over the looker closure passed in. This PR added a non-trivial chunk of code to it, which is now getting monomorphized a bunch more. I've added to my todo list to investigate whether changing the function to take the looker without monomorphization or outlining a chunk of the code makes sense.