Re: [PATCH v2 5/9] gdb/python: allow ref_ptr<T, Policy>::new_reference to accept subclasses of T

Tom Tromey
2026-03-06T16:47:58Z

>>>>> Matthieu Longo <matthieu.longo@arm.com> writes:

> After a deeper examination, I am not sure that your series helps much for this patch.

> * Case 1: return value from the registry.

> PyObject *result = (PyObject *) cfpy_inferior_corefile_data_key.get (inf);
> if (result != nullptr)
> return gdbpy_ref<>::new_reference (result);

> If I had gdbpy_borrowed_ref available, I could replace the code above by something like:
> gdbpy_borrowed_ref result = cfpy_inferior_corefile_data_key.get (inf);
> if (result != nullptr)
> return result; /* assuming that gdbpy_ref<> would have a constructor taking gdbpy_borrowed_ref. */

Ok, I see. Sorry about that.

Does the registry need to return a properly-typed one?
Perhaps it can just always return a gdbpy_ref<>.

> * Case 2: registration of the new object in the registry and return the value.

> gdbpy_ref<corefile_object> object
> (PyObject_New (corefile_object, &corefile_object_type));
> ...
> cfpy_inferior_corefile_data_key.set (inf, object.get ());
> return gdbpy_ref<>::new_reference (object.release ());

Here the release stuff is no longer needed as upcasting works fine:

cfpy_inferior_corefile_data_key.set (...);
return object;

> However, I am getting further from my original objective, which was only flattening the code for upcoming changes.
> All those improvements seem to me out of scope of my original patch.

Yeah. It's fine to take small steps and not do too much.
So if it's convenient just go ahead; but if you don't mind add a bit of
explanation to the commit message.

thanks,
Tom