Re: [PATCH v2] gdb: use gdb::unordered_{set,map} at a few places

[Simon Marchi <simark@simark.ca>]

On 2025-11-14 14:49, Tom Tromey wrote:
>>>>>> "Simon" == Simon Marchi <simon.marchi@efficios.com> writes:
> 
> Simon> New in v2:
> Simon>  - I forgot to actually build-test with all targets enabled, so I was
> Simon>    missing a change in solib-rocm.c.
> 
> Simon> Use the gdb:: set/map types instead of the std:: ones.  I only changed
> Simon> places in files I can build on my dev machine.
> 
> Simon> I needed to explicitly default the move constructor and assigment
> Simon> operator in proc_mem_file.  I think this is ok, as nothing takes the
> Simon> address of a proc_mem_file, requiring it not to move.
> 
> Simon> I also needed to do it for refcnt_fd, in solib-rocm.c.  It's a bit odd
> Simon> to prevent moving / copying a refcnt_fd, as this struct doesn't directly
> Simon> hold a resource, but I think I get why it was done.
> 
> The patch removes DISABLE_COPY_AND_ASSIGN from refcnt_fd, but that seems
> like it shouldn't be needed -- the map should handle move-only types
> fine, and I think proc_mem_file is already one such.
> 
> Simon>    struct refcnt_fd
> Simon>    {
> Simon> -    DISABLE_COPY_AND_ASSIGN (refcnt_fd);
> Simon>      refcnt_fd (int fd, int refcnt) : fd (fd), refcnt (refcnt) {}
> 
> i.e. this change seems unnecessary.
> 
> Adding DISABLE_COPY_AND_ASSIGN to proc_mem_file isn't really need, since
> it's handled by scoped_fd, though maybe it's worthwhile for clarity.

I'm a bit confused with your answer.  But if I don't explicitly default
the move constructor and move assignment operator in proc_mem_file, it
won't build.  I would have expected proc_mem_file to automatically have
them since its scoped_fd field already is movable.  I don't understand
what makes it non-movable unless I explicitly default the operations.

Simon