regexp-make-js
regexp-make-js copied to clipboard
mikesamuel
Disallow irregular patterns
The current regex grammar is quite liberal about SyntaxCharacters that appear in places where they are not allowed. For example, /a{/ is just taken literally.
This complicates parsing, and deciding what context we are in to escape the interpolation value. As an example, what would RegExp.make a{${"1,}b"}do, is it equivalent to/a{1,}b/`?
We should ensure that only well-formed patterns (where interpolation "holes" can produce Atoms, DecimalDigits etc) are allowed as arguments to make, and everything else throw a SyntaxError.
It'd be ideal if we didn't have to use try/catch to handle error cases :-/ one of the primary use cases is handling user input, and if it could throw (like JSON.parse) then our code has to be littered with try/catches, or wrapped in a Promise.
@ljharb Nah, I meant that RegExp.make a{ ${input}`` always throws, regardless of the user input, because unmatched braces are a programmer mistake (and make the implementation of make harder).
Of course, RegExp.make would not throw on the interpolation values (as long as they have the expected Type, e.g. string/regex, and don't throw on coercion); all character sequences are valid and do not need to meet any pattern.
So throw on errors in literal sections per early errors but should never throw because of an interpolated value?
Well, it wouldn't be exactly a compile-time early error (like they are possible for regex literals), as RegExp.make gets to see the raw strings not before its invocation, but yes, it would only throw these errors because of syntactic issues in the literal sections. Interpolation values are always escaped literally, and don't need to conform to any syntactic grammar.
should never throw because of an interpolated value?
OT, but a strict "never" is not possible of course. We will always need to throw in cases like
RegExp.make `x{${ -1 }}` // repeat -1 times
RegExp.male `^${ {toString(){ throw "buh!"; }} }` // better not coerce that
To precise: RegExp.make must never throw when interpolating a primitive string value in the context of an Atom (the original purpose of RegExp.escape).
Fair enough.
So constructs that are problematic from regexp_match_web_reality:
\cnot followed by a control code\xnot followed by 2 x hex and\unot followed by (4 x hex or{hex+}){not followed by a proper range then a}or not interpolable to the same.[not closed by a]- character groups like
\wused in a charset range - zero-width assertions like
\Bused in a charset.
Not on that list, but patterns that could indicate a disconnect between author and interpreter:
(?followed by a character that has a special meaning in other regular expression systems like(?i:,(?i,(?<!- unicode character classes
\p,[:Lu:]in character classes.
Oh, there's already a list of them? Yeah, it would be nice if we could deprecate them right from the beginning :-) I'm specifically concerned about everything that would change the context for interpolation holes, like 3) for quantifiers or 4) for classes, but might not if it's not properly closed. Also the incomplete escape sequences are a hazard if directly followed by an interpolated value.
I think we will need to allow those patterns like (?i:, (?i, (?<! though, as they could be used by an extend regular grammar (of the engine) or a subclass (userland). RegExp.make doesn't need to deal with them; if not supported the RegExp constructor will throw on them anyway (or are the browsers where it doesn't?).
However, a pattern like …(?${input})… should be considered irregular indeed.
Agreed on (?${input}).
To summarize:
We should fail on interpolations in some contexts.
\c${...}\u${...}\x${...}(?${...})`
Re lookbehind, should we dissallow interplations in
(?<${...})
where the valence of the interpolation has not yet been specified.
What about in charsets on either side of a -?
[a-${...}][${...}-z]