rust/hg-cpython/src/exceptions.rs
author Raphaël Gomès <rgomes@octobus.net>
Tue, 09 Jul 2019 15:15:54 +0200
changeset 42752 30320c7bf79f
parent 42609 326fdce22fb2
child 42957 7a01778bc7b7
permissions -rw-r--r--
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

// 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);