Looks highly plausible. Add / adapt a test to verify that this predicate in fact never worked?

Why does this need a QL-level fix? The backslash character isn't special in a matches context, so it shouldn't need to be escaped, right? To me, this fix look wrong.

Or am I misremembering? Is backslash the escape character for _ and %?

The argument is a pattern that matches the receiver, in the same way as the LIKE operator in SQL. Patterns may include _ to match a single character and % to match any sequence of characters. A backslash can be used to escape an underscore, a percent, or a backslash. Otherwise, all characters in the pattern other than _ and % and \\ must match exactly.

Found it. However, the description doesn't state how single backslashes that aren't followed by backslash, underscore, or percent are interpreted. I'd expect them to match a single backslash, and not silently fail the entire match - if so, then the QL ought to have raised a warning. Given how few features a matches spec has, would it make sense to have all strings be valid input, i.e. allow such stray backslashes to match as if they were escaped?

Or am I misremembering? Is backslash the escape character for _ and %?

Backslash is indeed the escape character (see inmemory/src/com/semmle/inmemory/ast/RegexpUtils.java).

The argument is a pattern that matches the receiver, in the same way as the LIKE operator in SQL. Patterns may include _ to match a single character and % to match any sequence of characters. A backslash can be used to escape an underscore, a percent, or a backslash. Otherwise, all characters in the pattern other than _ and % and \\ must match exactly.

Found it. However, the description doesn't state how single backslashes that aren't followed by backslash, underscore, or percent are interpreted. I'd expect them to match a single backslash, and not silently fail the entire match - if so, then the QL ought to have raised a warning. Given how few features a matches spec has, would it make sense to have all strings be valid input, i.e. allow such stray backslashes to match as if they were escaped?

There are a couple of points that need clarification here:

• The compiler does generate a warning, but only logs it in a very late compiler pass. Everybody agrees that "then the QL ought to have raised a warning" - that's what I'm working on.
• The match is not failing. The evaluator behaves as you suggest and will continue to do so. Hence, this warning is just a genuine warning to the user along the lines of "are you sure you don't have a typo here?".
• it would be perfectly possible to simply remove the warning if that's seen as preferable.

• The compiler does generate a warning, but only logs it in a very late compiler pass. Everybody agrees that "then the QL ought to have raised a warning" - that's what I'm working on.
• The match is not failing. The evaluator behaves as you suggest and will continue to do so. Hence, this warning is just a genuine warning to the user along the lines of "are you sure you don't have a typo here?".
• it would be perfectly possible to simply remove the warning if that's seen as preferable.

Ah, makes more sense to me now, then. I guess that late compiler warning will then simply be removed? Since the matches string could have come from somewhere where it wasn't possible to give an early warning.

I don't have a strong opinion on the matter, but I think I slightly prefer removing the warning completely (and updating the documentation to state that solitary backslash works the same as an escaped backslash (assuming that it isn't followed by underscore or percent)).

We have decided that it is easier to just support the existence of solitary backspaces in this context.