@mathias Are regexes intentionally not verified in lazy parsed func bodies?
```
function f(){ /)/ }
() => /)/
[{l(){ /)/ }}]
```
Does throw for `/)/` in toplevel or inside toplevel expression or in iife...
Oh no! :P
To be fair, @verwaest recently fixed the non-RegExp cases (late → early errors) as part of his work on the parser: https://v8.dev/blog/preparser#teaching-the-preparser-about-variables … RegExp is a different beast, though. cc @hashseed @schuay @peterwmwong
-
-
Yup, totally reasonable. Was just checking whether it was expected or not. I kind of expected the lazy parsing to be the cause and it to be a wontfix. So anything better than that is good :)
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
I fixed all variable conflicts early errors, I didn't look at regexp scanning. (Although verwaest@ is also a Toon, please refer to tverwaes@ :-))
-
Most subtly confusing GitHub/Twitter/Chromium username combo ever
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
JavaScript, HTML, CSS, HTTP, performance, security, Bash, Unicode, i18n, macOS.