Emit a warning if a match is too complex

[GuillaumeGomez]

Based on the results of crater run from #121979, we can safely set this limit without introducing regressions in the current rust ecosystem.

Follow-up of #121917.

r? @Nadrieril

[rustbot]

Some changes occurred in exhaustiveness checking

cc @Nadrieril

[rustbot]

Some changes occurred in match checking

cc @Nadrieril

[Nadrieril]

Suggested change

	// Default value to emit the warning for "too complex" match. We picked it based on
	// this crater run: <https://github.com/rust-lang/rust/pull/121979>.
	.or(Some(10_000_000));
	// Default value to emit the warning for "too complex" match. We picked it to warn after a second or two.
	.or(Some(10_000_000));

I don't think the crater matters much to future readers of this code, but the timing intent does.

[Nadrieril]

Actually you said that limit took more like 20s on your machine? I'd be curious to crater a lower limit then, because I'm afraid people won't wait 20s

[GuillaumeGomez]

Fine by me!

[Nadrieril]

Beautiful :D One last remark

[Nadrieril]

Dear T-lang, this PR adds a warning that cannot be silenced, triggered when a match takes a really long time to analyze (in the order of seconds). This is to help users figure out what's taking so long and fix it.

We could make the limit configurable or the warning allowable. I argue that's not necessary because crater showed zero regressions with the current limit, and it's be pretty easy in general to split up a match into smaller matches to avoid blowup.

We're still figuring out the exact limit, but does the team approve in principle?

[GuillaumeGomez]

Updated!

[GuillaumeGomez]

Fixed typo.

[traviscross]

Those interested in pushing the limits of exhaustiveness checking may be interested in:

• Compiling Rust is NP-hard
• rustc-sat

[bors]

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

[GuillaumeGomez]

Any update here?

[traviscross]

No, we're still working to get to this one on our nominations list.

Looking at this myself, though, one thought. I think I'd prefer it to be possible to allow this, and that such a change would make this an easier call for us when we pick it up in a meeting. Crater doesn't necessarily represent the full ecosystem, and if someone does hit this and is willing to pay the compilation cost, I don't really see a reason to force that person to rewrite the code or live with an unsilenceable warning.

[Nadrieril]

This is not just a lint, it's more accurately compared to overflow in the trait system (IIUC): it's a failure condition where the compiler says "this is too hard for me" to avoid looping for unbounded time

[traviscross]

I don't know. It still feels lint-like to me. It's just an arbitrary limit¹. When it fires, it's not saying that "this is too hard for me"² it's saying "this might take longer to compute than an arbitrarily-decided number of cycles".

So it's "linting" against code that would require more than that number of cycles.

Footnotes

1. I.e., we're not coming up against a "real" resource limit here, like some fixed-size buffer. ↩

2. We know from prior work that rustc can handle rather complex matches if given enough time. ↩

[Nadrieril]

it's not saying that "this is too hard for me" it's saying "this might take longer to compute than an arbitrarily-decided number of cycles"

Except that if we reached the limit it's quite likely that we're hitting an exponential case, in which case the computation may need days to complete.

If we can't allow the warning there should be a way to increase the pattern complexity limit to silence the warning, I do agree there.