Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

escape into a formatter #435

Closed
jethrogb opened this issue Dec 29, 2017 · 3 comments
Closed

escape into a formatter #435

jethrogb opened this issue Dec 29, 2017 · 3 comments
Labels

Comments

@jethrogb
Copy link

Currently, escape allocates a new string for its output. It's often the case that you want to use the output of escape in a larger string to specify the regex. It would be more convenient if the escaping method implements Display so it can be used directly in a format string without allocation. To get an allocated string, one can then always use the to_string method.

Suggested API:

struct Escape { ... }

impl Escape {
  fn new(text: &str) -> Self { ... }
}

impl Display for Escape { ... }
@BurntSushi
Copy link
Member

BurntSushi commented Dec 29, 2017

I guess in principle I agree, but can you actually come up with a benchmark where this matters? I'd be surprised if you could. The benchmark should include regex compilation. My instinct is that these sorts of allocations would be dwarfed by the compilation process itself.

@RReverser
Copy link
Contributor

RReverser commented Feb 23, 2018

Alternatively, it could return an iterator like std library does for EscapeDefault and EscapeDebug, then you can either .collect() to String or .extend existing String (and it will be more consistent with std).

BurntSushi added a commit to BurntSushi/regex that referenced this issue Mar 5, 2018
This commit represents a ground up rewrite of the regex-syntax crate.
This commit is also an intermediate state. That is, it adds a new
regex-syntax-2 crate without making any serious changes to any other
code. Subsequent commits will cover the integration of the rewrite and
the removal of the old crate.

The rewrite is intended to be the first phase in an effort to overhaul
the entire regex crate. To that end, this rewrite takes steps in that
direction:

* The principle change in the public API is an explicit split between a
  regular expression's abstract syntax (AST) and a high-level
  intermediate representation (HIR) that is easier to analyze. The old
  version of this crate mixes these two concepts, but leaned heavily
  towards an HIR. The AST in the rewrite has a much closer
  correspondence with the concrete syntax than the old `Expr` type does.
  The new HIR embraces its role; all flags are now compiled away
  (including the `i` flag), which will simplify subsequent passes,
  including literal detection and the compiler. ASTs are produced by
  ast::parse and HIR is produced by hir::translate. A top-level parser
  is provided that combines these so that callers can skip straight from
  concrete syntax to HIR.
* Error messages are vastly improved thanks to the span information that
  is now embedded in the AST. In addition to better formatting, error
  messages now also include helpful hints when trying to use features
  that aren't supported (like backreferences and look-around). In
  particular, octal support is now an opt-in option. (Octal support
  will continue to be enabled in regex proper to support backwards
  compatibility, but will be disabled in 1.0.)
* More robust support for Unicode Level 1 as described in UTS#18.
  In particular, we now fully support Unicode character classes
  including set notation (difference, intersection, symmetric
  difference) and correct support for named general categories, scripts,
  script extensions and age. That is, `\p{scx:Hira}` and `p{age:3.0}`
  now work. To make this work, we introduce an internal interval set
  data structure.
* With the exception of literal extraction (which will be overhauled in
  a later phase), all code in the rewrite uses constant stack space,
  even while performing analysis that requires structural induction over
  the AST or HIR. This is done by pushing the call stack onto the heap,
  and is abstracted by the `ast::Visitor` and `hir::Visitor` traits.
  The point of this method is to eliminate stack overflows in the
  general case.

The principle downsides of these changes are parse time and binary size.
Both seemed to have increased (slower and bigger) by about 1.5x. Parse
time is generally peanuts compared to the compiler, so we mostly don't
care about that. Binary size is mildly unfortunate, and if it becomes a
serious issue, it should be possible to introduce a feature that
disables some level of Unicode support and/or work on compressing the
Unicode tables. Compile times have increased slightly, but are still a
very small fraction of the overall time it takes to compile `regex`.

Fixes rust-lang#174, Fixes rust-lang#424, Fixes rust-lang#435
@BurntSushi
Copy link
Member

If someone can give me a good use case for avoiding allocation for something like this, then I'd be happy to revisit an API like this. But otherwise I don't think it's worth doing.

@BurntSushi BurntSushi closed this as not planned Won't fix, can't repro, duplicate, stale Mar 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants