Regex lints

[killercup]

I'm not sure whether there are lints for external crates yet, but I have some ideas for regex! (@BurntSushi might have some more.)

• Warn that (currently) the regex! compiler macro is slower than the run time engine
• Analyze trivial regexes and suggest std::str methods
• Use regex-syntax to validate (static) regexes at compile time (when not using the regex! macro)
• Recognize consecutive regex calls on the same string and suggest combining the regexes so there only needs to be one pass over the string

I'm sure these are quite hard. So, if anyone is looking for a challenge…

[llogiq]

With @mcarton's latest addition to our utility belt (a function that matches the bang macro name) the first shouldn't be too hard – although it has probably only temporary value.

The second shouldn't be hard at all; at least for simple cases. Likewise the third; we can use const_eval::eval_const_expr_partial(..) to get the regex and check it.

Recognizing consecutive regex calls on the same string sounds much harder – especially making sure that the string wasn't changed in the meantime...

Apart from that, I suggest adding one issue per lint; this makes it easier to manage.

[BurntSushi]

@llogiq's right in that regex! being slower than Regex::new is temporary, although my guess is that it will be that way for quite a while to come. In fact, it will get worse before it gets better. (I'm focusing most of my energy on improving dynamic regexes.)

Recognizing consecutive regex calls could be quite tricky, and combining the regexes isn't always a straight-forward transformation and it may not always be trivially possible. For example, multiple regexes might detect overlapping matches, but if you combine them into one alternation, then only non-overlapping matches are reported. The "right" solution to this is for the regex library to offer up a way to execute multiple regexes (and report overlapping matches, for example).

The biggest most important thing for regexes is to make sure you aren't compiling them every time you execute a search. I see it a lot in beginner code. Usually sticking them in lazy_static! is sufficient. But I suspect that might also be hard to detect.

[llogiq]

We could lint compiling a regex within a loop. Does that make sense?

[BurntSushi]

@llogiq That definitely seems like something you generally wouldn't want to do, unless of course, you're iterating over strings to compile as regexes. :P

[llogiq]

We may even be able to check the data flow if the argument for the regex comes from the iterator and bail in those cases.

[killercup]

The second shouldn't be hard at all; at least for simple cases.

Yeah, it's basically only contains and {starts,ends}_with with string pattern.

Apart from that, I suggest adding one issue per lint; this makes it easier to manage.

Feel free to do that (though this issue contains an awesome progress bar in the listing 😉) I'll do that.

[llogiq]

Thank you!