Merge #10949

10949: Bump parser step limit a little r=lnicola a=lnicola

Fixes #10948

This doesn't actually make the limit configurable, but at least uses the same `Limit` struct, so we can fix all of them at once when we get to it.

We also bump the limit from 10 to 15M, which is a small enough increase to not worry about making the experience worse for non-`windows` users. We still crash when we reach the limit.

bors r+

Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>

Cargo.lock

@@ -1071,6 +1071,7 @@ name = "parser"
 version = "0.0.0"
 dependencies = [
  "drop_bomb",
+ "limit",
 ]
 
 [[package]]

crates/parser/Cargo.toml

@@ -11,3 +11,5 @@ doctest = false
 
 [dependencies]
 drop_bomb = "0.1.4"
+
+limit = { path = "../limit", version = "0.0.0" }

crates/parser/src/parser.rs

@@ -3,6 +3,7 @@
 use std::cell::Cell;
 
 use drop_bomb::DropBomb;
+use limit::Limit;
 
 use crate::{
     event::Event,
@@ -26,6 +27,8 @@ pub(crate) struct Parser<'t> {
     steps: Cell<u32>,
 }
 
+static PARSER_STEP_LIMIT: Limit = Limit::new(15_000_000);
+
 impl<'t> Parser<'t> {
     pub(super) fn new(token_source: &'t mut dyn TokenSource) -> Parser<'t> {
         Parser { token_source, events: Vec::new(), steps: Cell::new(0) }
@@ -48,7 +51,7 @@ pub(crate) fn nth(&self, n: usize) -> SyntaxKind {
         assert!(n <= 3);
 
         let steps = self.steps.get();
-        assert!(steps <= 10_000_000, "the parser seems stuck");
+        assert!(PARSER_STEP_LIMIT.check(steps as usize).is_ok(), "the parser seems stuck");
         self.steps.set(steps + 1);
 
         self.token_source.lookahead_nth(n).kind