Also, rust-cpython will need tests to upstream. I also think that it's a good idea to have tests when dealing with unsafe boundaries.

On 10/10/19 9:21 PM, Raphaël Gomès wrote:
Indeed, I don't think there is a way to prevent this. We might get additional feedback when upstreaming to rust-cpython though.

Rest of the series looks good to me. This is all a needed improvement.

On 10/10/19 4:34 PM, Yuya Nishihara wrote:
On Thu, 10 Oct 2019 13:53:54 +0200, Raphaël Gomès wrote:
Is it not possible to just take a `fn` type? It forces a non-capturing fn.
Interesting idea, but still fn() would allow mutating a static variable.
IIRC, mutation of static variable can be safely written by using lazy_static
and Mutex.

On 10/8/19 7:16 PM, Yuya Nishihara wrote:
+    pub fn map<U>(
+        mut self,
+        py: Python,
+        f: impl FnOnce(T) -> U,
+    ) -> PyLeakedRef<U> {
+        PyLeakedRef {
+            inner: self.inner.clone_ref(py),
+            data: Some(f(self.data.take().unwrap())),
+            py_shared_state: self.py_shared_state,
+        }
+    }
I'm feeling that it's good to leave leaked_ref.map() unsafe. The new API
should be less error-prone, and its safety requirement, "don't leak the
static reference", can be easily guaranteed.
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Reply via email to