On Mon, Mar 02, 2026 at 09:38:41PM -0500, Jason Merrill wrote:
> On 3/2/26 7:25 AM, Thomas Berger wrote:
> > The ordering logic of class_members_of is based on the DECL_UIDs
> > for the class members. While this works for non-imported types,
> > it breaks for imported classes and their members.
> >
> > As DECL_UID is the only existing indicator of declaration order, we
> > preserve the original DECL_UID in the CMI for relevant class members.
>
> Could we use DECL_SOURCE_LOCATION instead?
Would that be reliable?
I mean, when location_t was 32-bit, there were points where we'd stop
first tracking token ranges, then columns, then even lines, so at some
point DECL_SOURCE_LOCATION could be say equal even when DECL_UID would
be different. I think such a case is still there even with 64-bit
location_t, although probably harder to trigger (dunno if #line directives
jumping by billions of lines up and down won't trigger it quickly though).
Also, is DECL_SOURCE_LOCATION of class or namespace decls never using
IS_ADHOC_LOC locations? This one could be handled through LOCATION_LOCUS
of course.
And even on a trivial
struct S { union { int a; }; };
the DECL_SOURCE_LOCATION order of TYPE_FIELDS doesn't match DECL_UID order
of those.
There is D.2986 FIELD_DECL, S self-reference and ._anon_0 TYPE_DECL and
(gdb) p ((tree)0x7fffe99e31e0)->decl_minimal.locus
$4 = 1035396
(gdb) p ((tree)0x7fffe99e31e0)->common.chain->decl_minimal.locus
$5 = 1035136
(gdb) p ((tree)0x7fffe99e31e0)->common.chain->common.chain->decl_minimal.locus
$6 = 1036160
(gdb) p ((tree)0x7fffe99e31e0)->decl_minimal.uid
$7 = 2986
(gdb) p ((tree)0x7fffe99e31e0)->common.chain->decl_minimal.uid
$8 = 2982
(gdb) p ((tree)0x7fffe99e31e0)->common.chain->common.chain->decl_minimal.uid
$9 = 2983
So, DECL_UID ordering puts ._anon_0 first and D.2986 second, while
DECL_SOURCE_LOCATION ordering would do the reverse.
Also, unsure about location_t when decls come from different modules e.g.
when merging the same class from multiple sources (if that is possible).
Jakub
