panic with regex-fancy feature on one line JS files

[Canop]

With current main (commit 3e07483):

echo "let a = 0;" > crash.js
cargo run --no-default-features --features "clap,etcetera,paging,wild,regex-fancy" -- crash.js

results in

thread 'main' panicked at /home/dys/.cargo/registry/src/index.crates.io-6f17d22bba15001f/syntect-5.2.0/src/parsing/regex.rs:70:53:
regex string should be pre-tested: ParseError(147, InvalidEscape("\\g"))

It may be due to https://github.com/sublimehq/Packages/blob/master/JavaScript/Indentation%20Rules.tmPreferences#L73

The reason I want to use regex-fancy is that the onig crate fails to build with gcc 15.

Background: I'm the author of another program using syntect, I have the same problem and just verified it was also happening in bat. A solution should apply to both bat and broot.

[Canop]

The solution I used in broot was to use a forked version of syntect to prevent panics (and not applying not computable rules).

A more general solution might be to do a PR for syntect, adding a no-panic mode. I don't know if that would be of interest for bat.

[keith-hall]

I believe it would be useful for bat. Better to have slightly wrong highlighting than panicking halfway through I think 🙂

[Canop]

I believe it would be useful for bat. Better to have slightly wrong highlighting than panicking halfway through I think 🙂

So I'll try to propose a clean PR to syntect.

[Canop]

@keith-hall Can you please have a look at trishume/syntect#564 and give me your opinion ?

This is the exact code of the fork used in broot current's main, avoiding runtime panics.

[keith-hall]

Seems reasonable to me :) btw I tracked the incompatible regex pattern down to https://github.com/babel/babel-sublime/blob/f4579f9107996c16208466248a85dc2296083a5f/JavaScript%20(Babel).YAML-tmLanguage#L357

[Canop]

@keith-hall Any idea to unblock this PR ?

[keith-hall]

I guess it makes sense to get CI passing as much as possible - the bat regression tests step is expected to fail due to the public API changing, so I think either we ignore it or (temporarily) point it to a branch of bat which would compile against the new version of syntect. As there is likely no way to make the PR smaller, I think it should be fine.