upstream/mercurial-mirror Files · rust/hg-core/src/re2/mod.rs

debugmergestate: make templated...

debugmergestate: make templated Our IntelliJ team wants to be able to read the merge state in order to help the user resolve merge conflicts. They had so far been reading file contents from p1() and p2() and their merge base. That is not ideal for several reasons (merge base is not necessarily the "graft base", renames are not handled, commands like `hg update -m` is not handled). It will get especially bad as of my D7827. This patch makes the output s a templated. I haven't bothered to make it complete (e.g. merge driver states are not handled), but it's probably good enough as a start. I've done a web search for "debugmergestate" and I can't find any indication that any tools currently rely on its output. If it turns out that we get bug reports for it once this is released, I won't object to backing this patch out on the stable branch (and then perhaps replace it by a separate command, or put it behind a new flag). Differential Revision: https://phab.mercurial-scm.org/D8113

Raphaël Gomès - - Load All Authors

File last commit:

r44786:d8d4fa9a default


                r44841:088ab52a

default

Download file

             mod.rs
        
                    21 lines
            
             | 1.0 KiB
            
                | application/rls-services+xml
            
             |
                RustLexer
            
             / rust / hg-core / src / re2 / mod.rs
          
                    History
                
                 |
                  Annotation
                 | Raw
                 |Copy content
                 |Copy permalink

      /// re2 module

      ///

      /// The Python implementation of Mercurial uses the Re2 regex engine when

      /// possible and if the bindings are installed, falling back to Python's `re`

      /// in case of unsupported syntax (Re2 is a non-backtracking engine).

      ///

      /// Using it from Rust is not ideal. We need C++ bindings, a C++ compiler,

      /// Re2 needs to be installed... why not just use the `regex` crate?

      ///

      /// Using Re2 from the Rust implementation guarantees backwards compatibility.

      /// We know it will work out of the box without needing to figure out the

      /// subtle differences in syntax. For example, `regex` currently does not

      /// support empty alternations (regex like `a||b`) which happens more often

      /// than we might think. Old benchmarks also showed worse performance from

      /// regex than with Re2, but the methodology and results were lost, so take

      /// this with a grain of salt.

      ///

      /// The idea is to use Re2 for now as a temporary phase and then investigate

      /// how much work would be needed to use `regex`.

      mod re2;

      pub use re2::Re2;

	Site-wide shortcuts
/	Use quick search box
g h	Goto home page
g g	Goto my private gists page
g G	Goto my public gists page
g 0-9	Goto bookmarked items from 0-9
n r	New repository page
n g	New gist page

	Repositories
g s	Goto summary page
g c	Goto changelog page
g f	Goto files page
g F	Goto files page with file search activated
g p	Goto pull requests page
g o	Goto repository settings
g O	Goto repository access permissions settings
t s	Toggle sidebar on some pages

				/// re2 module
				///
				/// The Python implementation of Mercurial uses the Re2 regex engine when
				/// possible and if the bindings are installed, falling back to Python's `re`
				/// in case of unsupported syntax (Re2 is a non-backtracking engine).
				///
				/// Using it from Rust is not ideal. We need C++ bindings, a C++ compiler,
				/// Re2 needs to be installed... why not just use the `regex` crate?
				///
				/// Using Re2 from the Rust implementation guarantees backwards compatibility.
				/// We know it will work out of the box without needing to figure out the
				/// subtle differences in syntax. For example, `regex` currently does not
				/// support empty alternations (regex like `a\|\|b`) which happens more often
				/// than we might think. Old benchmarks also showed worse performance from
				/// regex than with Re2, but the methodology and results were lost, so take
				/// this with a grain of salt.
				///
				/// The idea is to use Re2 for now as a temporary phase and then investigate
				/// how much work would be needed to use `regex`.
				mod re2;
				pub use re2::Re2;