Make startswith, endswith work with Regex

[dalum]

The rationale behind this PR is two-fold.

The first is motivated by a real use–case of checking the file extension of a file, where something like occursin(r"\.skf$"i, filename) seems to employ a "reverse query" logic to me that reduces readability: does this pattern, which must be at the end, occur in filename? Compared with: endswith(filename, r"\.skf"i): does filename have this pattern at the end?

The second is an argument about genericity, where a function such as occurs_not_endswith(pat, s) = occursin(pat, s) && !endswith(s, pat) presently wouldn't work for pat::Regex. I don't have a use for this, but it seems to me that it should work.

As an aside, the implementation here allows use such as endswith("abc\ndef", r"c"m) to check if any line in the string ends with "c".

The implementation of course has the slight overhead that if passed an already compiled Regex, this will generate and compile a new Regex on every call, but I would think that the cases where this is a real issue are not that frequent. And users who need this little bit of extra speed could probably be expected to understand the caveats of using a convenience function like the ones introduced here. 🙂

[dalum]

From suggestion by @ScottPJones, I changed the methods to use ANCHORED and ENDANCHORED in the compile options instead of manipulating the pattern. I had to add ENDANCHORED to the allowed COMPILE_MASK in pcre.jl, and I have no clue if there was a reason it was left out or not. At least the tests are passing locally, so hopefully there is no deeper meaning to its omission.

[StefanKarpinski]

Looks great. I like the version with anchor options very much.

[dalum]

The Windows 32 build is failing over something related to profiling. Can't quite figure out if it is related to this PR. 🤷‍♀️

[fredrikekre]

Add some simple docstrings?

[stev47]

Isn't the weirdness of occursin(r"\.skf$"i, filename) mostly a naming problem? A pattern doesn't "occur" in a string, it "matches" a string.
Extending methods startswith and endswith (that are used since the regex counterpart would be slower) to incorporate functionality that regex already delivers on might be unnecessary.
Thinking out loudly: somebody reading a regex pattern will also understand that one extra character ^ or $.

[KristofferC]

I think we need to address the 100x slowdown over occursin.

[dalum]

With the latest changes thanks to @chethega, this version is now only 1.3x slower than using occursin on my machine when the pattern doesn't match, and about 2x slower when the pattern matches. I will add a note to the docstrings mentioning that occursin should be preferred in performance critical situations.

1.3x seems good enough :)

[dalum]

Error messages during bootstrap are obscure. This bit meant that it failed to interpolate a $ inside a docstring: 😕

Core.CodeInfo(code=Array{Any, (2,)}[
  Expr(:call, :include, "regex.jl"),
  Expr(:return, nothing)], codelocs=Array{Int32, (2,)}[1, 1], method_for_inference_limit_heuristics=nothing, ssavaluetypes=2, linetable=Array{Any, (1,)}[Core.LineInfoNode(mod=Base, method=Symbol("top-level scope"), file=Symbol("Base.jl"), line=207, inlined_at=0)], ssaflags=Array{UInt8, (0,)}[], slotflags=Array{UInt8, (0,)}[], slotnames=Array{Any, (0,)}[], inferred=false, inlineable=false, propagate_inbounds=false, pure=false)Core.CodeInfo(code=Array{Any, (3,)}[
  Expr(:call, Core.getproperty, :Core, :(:include)),
  Expr(:call, SSAValue(1), :Main, "Base.jl"),
  Expr(:return, nothing)], codelocs=Array{Int32, (3,)}[1, 1, 1], method_for_inference_limit_heuristics=nothing, ssavaluetypes=3, linetable=Array{Any, (1,)}[Core.LineInfoNode(mod=Main, method=Symbol("top-level scope"), file=Symbol("sysimg.jl"), line=3, inlined_at=0)], ssaflags=Array{UInt8, (0,)}[], slotflags=Array{UInt8, (0,)}[], slotnames=Array{Any, (0,)}[], inferred=false, inlineable=false, propagate_inbounds=false, pure=false)

[dalum]

@StefanKarpinski @fredrikekre Ping! Tests are passing. I think it's ready now. 🎉