##// END OF EJS Templates
rust: fix unsound `OwningDirstateMap`...
rust: fix unsound `OwningDirstateMap` As per the previous patch, `OwningDirstateMap` is unsound. Self-referential structs are difficult to implement correctly in Rust since the compiler is free to move structs around as much as it wants to. They are also very rarely needed in practice, so the state-of-the-art on how they should be done within the Rust rules is still a bit new. The crate `ouroboros` is an attempt at providing a safe way (in the Rust sense) of declaring self-referential structs. It is getting a lot attention and was improved very quickly when soundness issues were found in the past: rather than relying on our own (limited) review circle, we might as well use the de-facto common crate to fix this problem. This will give us a much better chance of finding issues should any new ones be discovered as well as the benefit of fewer `unsafe` APIs of our own. I was starting to think about how I would present a safe API to the old struct but soon realized that the callback-based approach was already done in `ouroboros`, along with a lot more care towards refusing incorrect structs. In short: we don't return a mutable reference to the `DirstateMap` anymore, we expect users of its API to pass a `FnOnce` that takes the map as an argument. This allows our `OwningDirstateMap` to control the input and output lifetimes of the code that modifies it to prevent such issues. Changing to `ouroboros` meant changing every API with it, but it is relatively low churn in the end. It correctly identified the example buggy modification of `copy_map_insert` outlined in the previous patch as violating the borrow rules. Differential Revision: https://phab.mercurial-scm.org/D12429

File last commit:

r48583:6df528ed stable
r49864:dd6b67d5 stable
Show More
README.md
77 lines | 3.0 KiB | text/x-minidsrc | MarkdownLexer
Simon Sapin
rhg: Add build and config instructions to the README file...
r48583 # `rhg`
The `rhg` executable implements a subset of the functionnality of `hg`
using only Rust, to avoid the startup cost of a Python interpreter.
This subset is initially small but grows over time as `rhg` is improved.
When fallback to the Python implementation is configured (see below),
`rhg` aims to be a drop-in replacement for `hg` that should behave the same,
except that some commands run faster.
## Building
To compile `rhg`, either run `cargo build --release` from this `rust/rhg/`
directory, or run `make build-rhg` from the repository root.
The executable can then be found at `rust/target/release/rhg`.
## Mercurial configuration
`rhg` reads Mercurial configuration from the usual sources:
the user’s `~/.hgrc`, a repository’s `.hg/hgrc`, command line `--config`, etc.
It has some specific configuration in the `[rhg]` section:
* `on-unsupported` governs the behavior of `rhg` when it encounters something
that it does not support but “full” `hg` possibly does.
This can be in configuration, on the command line, or in a repository.
- `abort`, the default value, makes `rhg` print a message to stderr
to explain what is not supported, then terminate with a 252 exit code.
- `abort-silent` makes it terminate with the same exit code,
but without printing anything.
- `fallback` makes it silently call a (presumably Python-based) `hg`
subprocess with the same command-line parameters.
The `rhg.fallback-executable` configuration must be set.
* `fallback-executable`: path to the executable to run in a sub-process
when falling back to a Python implementation of Mercurial.
Antoine Cezar
rhg: add rhg crate...
r45503
Simon Sapin
rhg: Add build and config instructions to the README file...
r48583 * `allowed-extensions`: a list of extension names that `rhg` can ignore.
Mercurial extensions can modify the behavior of existing `hg` sub-commands,
including those that `rhg` otherwise supports.
Because it cannot load Python extensions, finding them
enabled in configuration is considered “unsupported” (see above).
A few exceptions are made for extensions that `rhg` does know about,
with the Rust implementation duplicating their behavior.
This configuration makes additional exceptions: `rhg` will proceed even if
those extensions are enabled.
## Installation and configuration example
For example, to install `rhg` as `hg` for the current user with fallback to
the system-wide install of Mercurial, and allow it to run even though the
`rebase` and `absorb` extensions are enabled, on a Unix-like platform:
* Build `rhg` (see above)
* Make sure the `~/.local/bin` exists and is in `$PATH`
* From the repository root, make a symbolic link with
`ln -s rust/target/release/rhg ~/.local/bin/hg`
* Configure `~/.hgrc` with:
```
[rhg]
on-unsupported = fallback
fallback-executable = /usr/bin/hg
allowed-extensions = rebase, absorb
```
* Check that the output of running
`hg notarealsubcommand`
starts with `hg: unknown command`, which indicates fallback.
* Check that the output of running
`hg notarealsubcommand --config rhg.on-unsupported=abort`
starts with `unsupported feature:`.