Skip to content
Snippets Groups Projects
  1. Feb 21, 2025
    • Mitchell Kember's avatar
      rust: enable workspace lints · 1ef08a0381a0
      Mitchell Kember authored
      This means that lints configured in rust/Cargo.toml will apply to all crates
      within the workspace. Currently there are none but I plan to add some.
      1ef08a0381a0
  2. Feb 18, 2025
  3. Jan 06, 2025
  4. Jan 07, 2025
  5. Dec 15, 2024
    • Georges Racinet's avatar
      rust-pyo3: initial port of PySharedRef · be765f6797cc
      Georges Racinet authored
      At this point, we have a full translation, with some tests.
      The tests are high level, demonstrating the case of iterating over
      `HashSet` as a doctest. The assertions are written as Python statements,
      in order not to be obscure and to resist later refactorings.
      The rust-cpython integration tests will be ported in a subsequent changeset.
      
      We find the example of iterating over `HashSet` to be more convincing than
      the iterating over `Vec`, the example provided in rust-cpython, because
      in the case of `Vec`, it would be simple enough to use `Arc<Vec>` and
      an index. This would of course be reimplementing the iterator, but is simple
      enough that it leads the reader to believe that having a reference is the
      problem, whereas the problem is having a reference that is itself enclosed
      in a type with lifetime that can be arbitrary complex. It took us some
      time to remember that subtlety, and hence we reworded the documentation
      to stress that point.
      
      We decided to put this work a separate crate, which makes running `cargo test`
      work for the crate, but not for the entire workspace: the `extension-module`
      feature gets in the way. That is why we reexpose the feature on `hg-pyo3` as
      default and run the tests with `--no-default-feature` in Makefile, hence in CI.
      
      An important difference with rust-cpython is that everything has to be `Sync`,
      hence we replace `RefCell` with `RwLock` and only speak of "interior mutability"
      in the documentation. Since everything happens in `hg-pyo3` behind the GIL,
      there is at this point no reason to use `read()` and `write()` instead of
      respectively `try_read()` and `try_write()`. But PyO3 is aiming to support
      free-threaded Python (without GIL), and `PySharedRef` should therefore
      allow waiting for its inner locks.
      be765f6797cc
  6. Dec 05, 2024
    • Georges Racinet's avatar
      rust-pyo3: conversions to GraphError Python exception · 6e8ba52857df
      Georges Racinet authored
      The nice thing is that with PyO3, exceptions can be instantiated
      without holding the GIL. Hence the only thing that prevents us to
      implement `Into<PyErr>` for `hg::GraphError` is that neither is
      defined by the current crate.
      
      We could use a wrapping "newtype", but the compiler is not so clever yet that
      it could chain automatically to two needed `into()`, so we'll end up with
      some type conversion anyway, involving something like `GraphErrorWrapper`.
      At this point, explicitly named methods are just simpler.
      6e8ba52857df
  7. Nov 30, 2024
    • Georges Racinet's avatar
      rust-pyo3: retrieving the InnerRevlog of hg-cpython · c2480ac4c5e2
      Georges Racinet authored
      This allows PyO3-based code to use the InnerRevlog, access its shared data
      (core InnerRevlog), which will then allow, e.g., to retrieve references on
      the core Index.
      
      On the `hg-cpython` (`rusthg` crate, `rustext` Python extension module),
      we had to also build as a Rust library, and open up some accesses (see
      notably the public accessor for `inner`, the core `InnerRevlog`).
      
      Retrieving the Rust struct underlying a Python object defined by another
      extension module written in Rust is tricky because the Python type objects
      are duplicated in the extension modules, leading to failure of the normal
      type checking. See the doc-comment of `convert_cpython::extract_inner_revlog`
      for a complete explanation.
      To solve this, we import the Python type object of `rustext` (defined
      by `hg-cpython`) and perform a manual check. Checking the Python type is
      necessary, as PyO3 documentation clearly state that downcasting an object
      that has not the proper type is Undefined Behaviour.
      
      At this point, we do not have conversion facilities for exceptions (`PyErr`
      on both sides), hence the remaining unwraps).
      c2480ac4c5e2
    • Georges Racinet's avatar
      rust-pyo3: conversion helpers for Revision objects · a642c0a3860f
      Georges Racinet authored
      Although the PyO3 API is indeed nicer and has derive macros, we still need
      the collection helpers. The `Result` issue is not very relevant any more,
      however the checking of incoming revisions for Python definitely is.
      a642c0a3860f
  8. Nov 20, 2024
  9. Nov 27, 2023
Loading