Skip to content

search: support /.../ regexp delimiters in new parser

Administrator requested to merge rvt/slash-slash into main

Created by: rvantonder

Our search docs describe support for /.../ syntax, but prior to this PR it wasn't supported in the new parser. This syntax has caused some trouble for users before, e.g., when they search for paths, and we throw an error. However, in that context, the previous scanner was a bit too strict, and would think that a search pattern like /foo/bar/baz/ also means a /-delimited string (but this would actually not be well-formed, since a / inside /.../ should be escaped). The scanner in the new parser is a bit smarter (so less opportunity for foot-shooting).

So, before:

/foo bar/ -> OK /foo/bar/ -> Error "Got TokenLiteral, want separator or EOF". To search for the string /foo/bar/, you needed to escape all of the slashes: \/foo\/bar\/ /foo\/bar -> OK, searches literally for foo/bar

Now:

/foo bar/ -> OK /foo/bar/ -> key difference: this is interpreted literally, since it is not a well-formed /.../ string, no need to escape anything /foo\/bar/ -> As above, it's a well-formed /.../ string, interpreted literally as foo/bar

There is a case to be made for deprecating this syntax, but because it is currently officially documented, we should support continue to support it and and then deprecate it officially if/when needed. With the improvement that it is now not so strict, and if we can highlight these delimiters in future so it's clear something is happening, I think it's still worth keeping.

Merge request reports