Summary:
Global states (For example, the global blackbox instance, potentially some
logging / tracing libraries) are separate in the Rust and Python worlds.
That is because related code gets compiled separately:
bindings.so (top-level)
\_ blackbox
hgmain (top-level)
\_ blackbox (have a different global instance than the above blackbox)
To address it, make `bindings` a builtin module in `hgmain`.
The builtin module was renamed from `edenscmnative.bindings` to `bindings` so
it does not require importing anything else (For example, `edenscmnative`).
This unfortunately makes `hg` 100+ MB. Fortunately it can be compressed well
(gzip: 31MB).
Reviewed By: singhsrb
Differential Revision: D17429688
fbshipit-source-id: bf16910d7a260ca58db0d272fc95d8071d47bbc6
Summary:
This just moves things around. So native and pure Python modules are split to
different Python packages. This makes it possible to use the standard zip
importer without hacks (ex. `hgdemandimport/embeddedimport`).
This diff is mostly about moving things. While `make local` still works,
it does break nupkg build, which will be fixed in a later diff.
Reviewed By: kulshrax
Differential Revision: D15798642
fbshipit-source-id: 5d83f17099aa198df0acd5b7a99667e2f35fe7b4
Summary:
Recently, the merge tools configs were moved from a file to a Rust
string. The path to these configs being empty, this caused the
stripping of '\\?\' on Windows to crash. Let's simply use "<builtin>"
in the `hg config --debug` output to signify an embedded config.
Reviewed By: quark-zju
Differential Revision: D15499196
fbshipit-source-id: 1141cfafde5ceae9c814ed711e00d93a4665c5fb
Summary:
Move all Rust bindings to a single python extension, `bindings`. This should
improve compilation time and make things simpler.
Reviewed By: quark-zju
Differential Revision: D13923866
fbshipit-source-id: 560592b5a6c0c4f1b836c755ef123666a1059164
Summary:
D13853115 adds `edenscm/` to `sys.path` and code still uses `import mercurial`.
That has nasty problems if both `import mercurial` and
`import edenscm.mercurial` are used, because Python would think `mercurial.foo`
and `edenscm.mercurial.foo` are different modules so code like
`try: ... except mercurial.error.Foo: ...`, or `isinstance(x, mercurial.foo.Bar)`
would fail to handle the `edenscm.mercurial` version. There are also some
module-level states (ex. `extensions._extensions`) that would cause trouble if
they have multiple versions in a single process.
Change imports to use the `edenscm` so ideally the `mercurial` is no longer
imported at all. Add checks in extensions.py to catch unexpected extensions
importing modules from the old (wrong) locations when running tests.
Reviewed By: phillco
Differential Revision: D13868981
fbshipit-source-id: f4e2513766957fd81d85407994f7521a08e4de48
Summary:
Update pest to 2.1.0.
This version has a new behaviour for parser error messages: the line feed at
the end of the line is shown in the error output.
Reviewed By: wez
Differential Revision: D13671099
fbshipit-source-id: b8d1142a44a56a0b21b3b72cf027f3f8a30f421e
Summary:
The test fails like:
```
--- test-configparser.t
+++ test-configparser.t.err
@@ -21,7 +21,7 @@
>>> from mercurial.rust import config
>>> cfg = config.config()
>>> cfg.readpath("a.rc", "readpath", None, None, None)
- ['"$TESTTMP/broken.rc":\n --> 1:2\n |\n1 | %not-implemented\n | ^---\n |\n = expected include or unset']
+ ['"\\\\\\\\\\\\\\\\?\\\\\\\\C:\\\\\\\\cygwin\\\\\\\\data\\\\\\\\sandcastle\\\\\\\\temp\\\\\\\\hgtests.ta2wor\\\\\\\\child187\\\\\\\\test-configparser.t\\\\\\\\broken.rc":\\n --> 1:2\\n |\\n1 | %not-implemented\\n | ^---\\n |\\n = expected include or unset']\r (esc)
>>> cfg.parse("[c]\nx=1", "parse")
[]
>>> cfg.set("d", "y", "2", "set1")
```
Not sure how `$TESTTMP` works. But let's repalce all of them to glob pattern as
an attempt to fix the test.
See https://fburl.com/sandcastle/pmirvy8a for full log.
Reviewed By: DurhamG
Differential Revision: D9281760
fbshipit-source-id: bb7319511bc8ffecba139bd608f47d7204853076
Summary:
The configsource line number is exposed in a bunch of UI and tests. Therefore
translate the bytes range to line numbers in the Python wrapper.
The Rust config parser does not track line numbers explicitly, as that adds
complexity to the parser.
The implemenation is inefficient. However, configsource is not used in
common code paths, so it'd be fine.
Reviewed By: DurhamG
Differential Revision: D8960868
fbshipit-source-id: 55e9f5170177e7cb4c8ef55ed17c1f85eb70a192
Summary:
Change the API to return parse errors directly, instead of keeping them in
ConfigSet struct. This makes it easier to get errors related to one of the
"parse" calls.
Reviewed By: DurhamG
Differential Revision: D8960869
fbshipit-source-id: fbd571f264415e788c5ac44961149d1498826a6d
Summary:
[pest](https://github.com/pest-parser/pest) is an elegant Rust library for
parsing text.
A navie benchmark on a 1MB config file shows pest is about 1.5 to 2x slower.
But the better error message and cleaner code seems worth it.
Practically, in a VirtualBox VM, parsing a set of our config files takes 3-7ms.
The overhead seems to be opening too many files. Reducing it to one file makes
parsing complete in 2-4ms.
Unfortunately the buck build has issues with the elegant syntax
`#[grammar = "spec.pest"]`, because "spec.pest" cannot be located by pest_derive.
Therefore a workaround is used to generate the parser.
The motivation behind this is because I noticed multi-line value can not be
taken as a plain Bytes slice. For example:
[section]
foo = line1
line2
"foo" should be "line1\nline2", instead of "line1\n line2". It does not make a
difference on configlist. But it affects templates. Rather than making the
parser more complex, it seems better to just adopt a reasonbly fast parsing
library.
Reviewed By: DurhamG
Differential Revision: D8960876
fbshipit-source-id: 2fa04e38b706f7126008512732c9efa168f84cc7
Summary: This allows the Python world to access its features.
Reviewed By: DurhamG
Differential Revision: D8790922
fbshipit-source-id: e7e561c86596159c3766d6da8e0834c6fe441cbd
