| 1 | /*! |
| 2 | Provides a regex matcher that composes several other regex matchers |
| 3 | automatically. |
| 4 | |
| 5 | This module is home to a meta [`Regex`], which provides a convenient high |
| 6 | level API for executing regular expressions in linear time. |
| 7 | |
| 8 | # Comparison with the `regex` crate |
| 9 | |
| 10 | A meta `Regex` is the implementation used directly by the `regex` crate. |
| 11 | Indeed, the `regex` crate API is essentially just a light wrapper over a meta |
| 12 | `Regex`. This means that if you need the full flexibility offered by this |
| 13 | API, then you should be able to switch to using this API directly without |
| 14 | any changes in match semantics or syntax. However, there are some API level |
| 15 | differences: |
| 16 | |
| 17 | * The `regex` crate API returns match objects that include references to the |
| 18 | haystack itself, which in turn makes it easy to access the matching strings |
| 19 | without having to slice the haystack yourself. In contrast, a meta `Regex` |
| 20 | returns match objects that only have offsets in them. |
| 21 | * At time of writing, a meta `Regex` doesn't have some of the convenience |
| 22 | routines that the `regex` crate has, such as replacements. Note though that |
| 23 | [`Captures::interpolate_string`](crate::util::captures::Captures::interpolate_string) |
| 24 | will handle the replacement string interpolation for you. |
| 25 | * A meta `Regex` supports the [`Input`](crate::Input) abstraction, which |
| 26 | provides a way to configure a search in more ways than is supported by the |
| 27 | `regex` crate. For example, [`Input::anchored`](crate::Input::anchored) can |
| 28 | be used to run an anchored search, regardless of whether the pattern is itself |
| 29 | anchored with a `^`. |
| 30 | * A meta `Regex` supports multi-pattern searching everywhere. |
| 31 | Indeed, every [`Match`](crate::Match) returned by the search APIs |
| 32 | include a [`PatternID`](crate::PatternID) indicating which pattern |
| 33 | matched. In the single pattern case, all matches correspond to |
| 34 | [`PatternID::ZERO`](crate::PatternID::ZERO). In contrast, the `regex` crate |
| 35 | has distinct `Regex` and a `RegexSet` APIs. The former only supports a single |
| 36 | pattern, while the latter supports multiple patterns but cannot report the |
| 37 | offsets of a match. |
| 38 | * A meta `Regex` provides the explicit capability of bypassing its internal |
| 39 | memory pool for automatically acquiring mutable scratch space required by its |
| 40 | internal regex engines. Namely, a [`Cache`] can be explicitly provided to lower |
| 41 | level routines such as [`Regex::search_with`]. |
| 42 | |
| 43 | */ |
| 44 | |
| 45 | pub use self::{ |
| 46 | error::BuildError, |
| 47 | regex::{ |
| 48 | Builder, Cache, CapturesMatches, Config, FindMatches, Regex, Split, |
| 49 | SplitN, |
| 50 | }, |
| 51 | }; |
| 52 | |
| 53 | mod error; |
| 54 | #[cfg (any(feature = "dfa-build" , feature = "hybrid" ))] |
| 55 | mod limited; |
| 56 | mod literal; |
| 57 | mod regex; |
| 58 | mod reverse_inner; |
| 59 | #[cfg (any(feature = "dfa-build" , feature = "hybrid" ))] |
| 60 | mod stopat; |
| 61 | mod strategy; |
| 62 | mod wrappers; |
| 63 | |