Add pyo3_leak_on_drop_without_reference_pool to turn aborts into leak…

…s when the global reference pool is disabled and the GIL is not held

guide/src/performance.md

@@ -101,7 +101,7 @@ impl PartialEq<Foo> for FooBound<'_> {
 
 PyO3 uses global mutable state to keep track of deferred reference count updates implied by `impl<T> Drop for Py<T>` being called without the GIL being held. The necessary synchronization to obtain and apply these reference count updates when PyO3-based code next acquires the GIL is somewhat expensive and can become a significant part of the cost of crossing the Python-Rust boundary.
 
-This functionality can be avoided by setting the `pyo3_disable_reference_pool` conditional compilation flag. This removes the global reference pool and the associated costs completely. However, it does _not_ remove the `Drop` implementation for `Py<T>` which is necessary to interoperate with existing Rust code written without PyO3-based code in mind. To stay compatible with the wider Rust ecosystem in these cases, we keep the implementation but abort when `Drop` is called without the GIL being held.
+This functionality can be avoided by setting the `pyo3_disable_reference_pool` conditional compilation flag. This removes the global reference pool and the associated costs completely. However, it does _not_ remove the `Drop` implementation for `Py<T>` which is necessary to interoperate with existing Rust code written without PyO3-based code in mind. To stay compatible with the wider Rust ecosystem in these cases, we keep the implementation but abort when `Drop` is called without the GIL being held. If `pyo3_leak_on_drop_without_reference_pool` is additionally enabled, objects dropped without the GIL being held will be leaked instead which is always sound but might have determinal effects like resource exhaustion in the long term.
 
 This limitation is important to keep in mind when this setting is used, especially when embedding Python code into a Rust application as it is quite easy to accidentally drop a `Py<T>` (or types containing it like `PyErr`, `PyBackedStr` or `PyBackedBytes`) returned from `Python::with_gil` without making sure to re-acquire the GIL beforehand. For example, the following code
 

pyo3-build-config/src/lib.rs

@@ -166,6 +166,7 @@ pub fn print_expected_cfgs() {
     println!("cargo:rustc-check-cfg=cfg(py_sys_config, values(\"Py_DEBUG\", \"Py_REF_DEBUG\", \"Py_TRACE_REFS\", \"COUNT_ALLOCS\"))");
     println!("cargo:rustc-check-cfg=cfg(invalid_from_utf8_lint)");
     println!("cargo:rustc-check-cfg=cfg(pyo3_disable_reference_pool)");
+    println!("cargo:rustc-check-cfg=cfg(pyo3_leak_on_drop_without_reference_pool)");
 
     // allow `Py_3_*` cfgs from the minimum supported version up to the
     // maximum minor version (+1 for development for the next)

src/gil.rs

@@ -455,7 +455,7 @@ pub unsafe fn register_decref(obj: NonNull<ffi::PyObject>) {
     } else {
         #[cfg(not(pyo3_disable_reference_pool))]
         POOL.register_decref(obj);
-        #[cfg(pyo3_disable_reference_pool)]
+        #[cfg(all(pyo3_disable_reference_pool, not(pyo3_leak_on_drop_without_reference_pool)))]
         {
             let _trap = PanicTrap::new("Aborting the process to avoid panic-from-drop.");
             panic!("Cannot drop pointer into Python heap without the GIL being held.");