State machine incorrectly treats division as the start of a regex

[amcasey]

e.g. in x / y, / y will be classified as a regex (to EOL).

To handle this properly, we'd need a parser - you need to know whether the slash is at the start of an expression. Offsets in the incorrectly classified region will (probably) map to the correct line but an incorrect character position, since trivia skipping rules are different within regexes.

[amcasey]

If the division were in an expression hole in a template literal, it might throw off brace or backtick matching for the rest of the file.

[amcasey]

My inclination is to spot fix issues as they come up but, if we really need to do this correctly, the best fix is probably to consume the real parser. Fitting that back into the offset normalization code is likely to be fidgety.