##// END OF EJS Templates
rust-cpython: add macro for sharing references...
rust-cpython: add macro for sharing references Following an experiment done by Georges Racinet, we now have a working way of sharing references between Python and Rust. This is needed in many points of the codebase, for example every time we need to expose an iterator to a Rust-backed Python class. In a few words, references are (unsafely) marked as `'static` and coupled with manual reference counting; we are doing manual borrow-checking. This changes introduces two declarative macro to help reduce boilerplate. While it is better than not using macros, they are not perfect. They need to: - Integrate with the garbage collector for container types (not needed as of yet), as stated in the docstring - Allow for leaking multiple attributes at the same time - Inject the `py_shared_state` data attribute in `py_class`-generated structs - Automatically namespace the functions and attributes they generate For at least the last two points, we will need to write a procedural macro instead of a declarative one. While this reference-sharing mechanism is being ironed out I thought it best not to implement it yet. Lastly, and implementation detail renders our Rust-backed Python iterators too strict to be proper drop-in replacements, as will be illustrated in a future patch: if the data structure referenced by a non-depleted iterator is mutated, an `AlreadyBorrowed` exception is raised, whereas Python would allow it, only to raise a `RuntimeError` if `next` is called on said iterator. This will have to be addressed at some point. Differential Revision: https://phab.mercurial-scm.org/D6631

File last commit:

r42979:826407e1 default
r42997:30320c7b default
Show More
exceptions.rs
71 lines | 2.2 KiB | application/rls-services+xml | RustLexer
// ancestors.rs
//
// Copyright 2018 Georges Racinet <gracinet@anybox.fr>
//
// This software may be used and distributed according to the terms of the
// GNU General Public License version 2 or any later version.
//! Bindings for Rust errors
//!
//! [`GraphError`] exposes `hg::GraphError` as a subclass of `ValueError`
//! but some variants of `hg::GraphError` can be converted directly to other
//! existing Python exceptions if appropriate.
//!
//! [`GraphError`]: struct.GraphError.html
use cpython::{
exc::{IOError, RuntimeError, ValueError},
py_exception, PyErr, Python,
};
use hg;
py_exception!(rustext, GraphError, ValueError);
impl GraphError {
pub fn pynew(py: Python, inner: hg::GraphError) -> PyErr {
match inner {
hg::GraphError::ParentOutOfRange(r) => {
GraphError::new(py, ("ParentOutOfRange", r))
}
hg::GraphError::WorkingDirectoryUnsupported => {
match py
.import("mercurial.error")
.and_then(|m| m.get(py, "WdirUnsupported"))
{
Err(e) => e,
Ok(cls) => PyErr::from_instance(py, cls),
}
}
}
}
}
py_exception!(rustext, PatternError, RuntimeError);
py_exception!(rustext, PatternFileError, RuntimeError);
impl PatternError {
pub fn pynew(py: Python, inner: hg::PatternError) -> PyErr {
match inner {
hg::PatternError::UnsupportedSyntax(m) => {
PatternError::new(py, ("PatternError", m))
}
}
}
}
impl PatternFileError {
pub fn pynew(py: Python, inner: hg::PatternFileError) -> PyErr {
match inner {
hg::PatternFileError::IO(e) => {
let value = (e.raw_os_error().unwrap_or(2), e.to_string());
PyErr::new::<IOError, _>(py, value)
}
hg::PatternFileError::Pattern(e, l) => match e {
hg::PatternError::UnsupportedSyntax(m) => {
PatternFileError::new(py, ("PatternFileError", m, l))
}
},
}
}
}
py_exception!(shared_ref, AlreadyBorrowed, RuntimeError);