This makes it so the permissions are locked down by default. The threat
model here is something like, "what happens if an authorized party gains
control of the non-PR CI configuration somehow."
To be honest, I (BurntSushi) don't quite understand how that might
happen without also the ability to set the permissions itself. But
locking permissions down by default does seem like a good and sensible
thing to do.
Closes#932
The previous implementation didn't bail out of the replace
loop when the limit was reached until one more than the
total number of 'find' operations had completed. By moving
the limit check to the end of the loop body, we execute only
the number of 'find' operations that is necessary, instead of
one extra.
This optimization only applies to 'replacen' calls with a limit
not equal to '0'. That includes 'replace' but not 'replace_all'.
PR #930
I didn't realize this was a useful build output for a C library, but I
guess it is. Namely, it permits it to be built with other rlibs into one
giant single shared library.
Fixes#909
Somewhat recently, 'CString::from_raw' got a '#[must_use]' slapped
on it. Arguably, writing 'drop' around its return value is indeed much
clearer. So we do that here.
We also do that for 'Box::from_raw' even though it doesn't have a
'#[must_use]' on it. But the same principle applies.
PR #882
Some lints have been intentionally ignored, especially:
* any lints that would change public APIs (like &self -> self)
* any lints that would introduce new public APIs (like Default over new)
Closes#780
Some lints have been intentionally ignored, especially:
* any lints that would change public APIs (like &self -> self)
* any lints that would introduce new public APIs (like Default over new)
Local benchmarks show up to 15% reduction in terms of number of
retired instructions executed and at least 5% reduction in terms
of CPU time.
This is basically a bit of a manual inlining here, instead of doing more
redirection.
PR #788
This adds an example of an intended pattern where the regex
set is used to find a matching regex, and then a separately
compiled regex is used to find where it matched.
PR #861
The docs are now updated to work with Unicode 14. (In particular,
emoji-data.txt no longer needs to be downloaded separately.) We also
include a note about adding a new case for "age" in regex-syntax.
I added this so that I can compare the results of the old benchmark
suite with the new one I'm working on in regex-automata. (The idea is to
port all or most of the benchmarks from the old suite and make sure the
results are at least roughly consistent.)
This is a perfect example of why adding support for more targets is
costly. Every so often, the cross compiling toolchain breaks for
mysterious reasons.
Previously, 'ab??' returned [Complete(ab), Complete(a)], but the order
matters here because of greediness. The correct result is [Complete(a),
Complete(ab)].
Instead of trying to actually fix literal extraction (which is a mess),
we just rewrite 'ab?' (and 'ab??') as 'ab*'. 'ab*' still produces
literals in the incorrect order, i.e., [Cut(ab), Complete(a)], but since
one is cut we are guaranteed that the regex engine will be called to
confirm the match. In so doing, it will correctly report 'a' as a match
for 'ab??' in 'ab'.
Fixes#862
This was incorrectly defined for \b. Previously, I had erroneously made
it return true only for \B since \B matches '' and \b does not match
''. However, \b does match the empty string. Like \B, it only matches a
subset of empty strings, depending on what the surrounding context is.
The important bit is that it can match *an* empty string, not that it
matches *the* empty string.
We were not yet using this predicate anywhere in the regex crate, so we
just fix the implementation and update the tests.
This does present a compatibility hazard for anyone who was using this
function, but as of this time, I'm considering this a bug fix since \b
clearly matches an empty string.
Fixes#859
This fixes a bug in how ASCII class unioning was implemented. Namely, it
previously and erroneously unioned together two classes and then applied
negation/case-folding based on the most recently added class, even if
the class added previously wasn't negated. So for example, given the
regex '[[:alnum:][:^ascii:]]', this would initialize the class with
'[:alnum:]', then add all '[:^ascii:]' codepoints and then negate the
entire thing because of the negation in '[:^ascii:]'. Negating the
entire thing is clearly wrong and not the intended semantics.
We fix this by applying negation/case-folding only to the class we're
dealing with, and then we union it with whatever existing class we're
building.
Fixes#680
