mirror of
https://github.com/facebook/sapling.git
synced 2024-12-29 08:02:24 +03:00
066f461bcf
Summary:
Edenapi uses a group of impls like the following as the canonical way to construct ApiError.
```
impl From<Context<ApiErrorKind>> for ApiError {
```
Downstream code would write:
```
use failure::ResultExt;
let stream_trees = config
.get_or_default("edenapi", "streamtrees")
.context(ApiErrorKind::BadConfig("edenapi.streamtrees"))?;
```
This relies on the way that ResultExt::context returns a unique type that is different from failure::Error.
This diff introduces a dedicated extension trait to allow the same code in the caller to continue to work even without a failure::Context<T> type, which will be required for dropping our dependency on failure::Fail and failure.
```
pub trait ApiErrorContext<T> {
fn context(self, kind: ApiErrorKind) -> ApiResult<T>;
}
```
We also introduce a public constructor for ApiError and replace indirect construction that used to look like this:
```
error.context(ApiErrorKind::Curl).into()
```
with this instead:
```
ApiError::new(ApiErrorKind::Curl, error)
```
which is the same number of characters but clearer. The argument order matches [std::io::Error::new](https://doc.rust-lang.org/std/io/struct.Error.html#method.new).
Reviewed By: kulshrax
Differential Revision: D18574668
fbshipit-source-id: 0a56297bb942a26d75a62ca39fc16abeb4486345
|
||
|---|---|---|
| .. | ||
| asyncrevisionstore/src | ||
| auth | ||
| backingstore | ||
| blackbox | ||
| bookmarkstore | ||
| cdatapack | ||
| clib | ||
| clidispatch | ||
| cliparser | ||
| commitcloudsubscriber | ||
| commitstore/bench-serialize | ||
| configparser | ||
| cpython-ext | ||
| cpython-failure | ||
| dag | ||
| drawdag | ||
| edenapi | ||
| encoding | ||
| hg_watchman_client | ||
| hgcommands | ||
| hgtime | ||
| indexedlog | ||
| linelog | ||
| lz4-pyframe | ||
| manifest | ||
| metalog | ||
| mincode | ||
| minibench | ||
| mpatch | ||
| mpatch-sys | ||
| mutationstore | ||
| nodemap | ||
| pathmatcher | ||
| procinfo | ||
| radixbuf | ||
| revisionstore | ||
| stackdesc | ||
| third-party | ||
| tracing-collector | ||
| treestate | ||
| types | ||
| util | ||
| vlqencoding | ||
| watchman_client | ||
| workingcopy | ||
| xdiff | ||
| xdiff-sys | ||
| zstdelta | ||
| zstore | ||
| CMakeLists.txt | ||
| README.md | ||
lib
Any native code (C/C++/Rust) that Mercurial (either core or extensions)
depends on should go here. Python code, or native code that depends on
Python code (e.g. #include <Python.h> or use cpython) is disallowed.
As we start to convert more of Mercurial into Rust, and write new paths entrirely in native code, we'll want to limit our dependency on Python, which is why this barrier exists.
See also hgext/extlib/README.md, mercurial/cext/README.mb.
How do I choose between lib and extlib (and cext)?
If your code is native and doesn't depend on Python (awesome!), it goes here.
Otherwise, put it in hgext/extlib (if it's only used by extensions) or
mercurial/cext (if it's used by extensions or core).