Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> On 11.07.22 01:09, Tom Lane wrote:
>> Andres Freund <andres@anarazel.de> writes:
> I was just rebasing meson ontop of this and was wondering whether the input
> filenames were in a particular order:
> First, things used by later files need to be found in earlier files. So
> that constrains the order a bit.
Yeah, the script needs to see supertype nodes before subtype nodes,
else it will not realize that the subtypes are nodes at all. However,
there is not very much cross-header-file subtyping. I experimented with
rearranging the input-file order, and found that the *only* thing that
breaks it is to put primnodes.h after pathnodes.h (which fails because
PlaceHolderVar is a subtype of Expr). You don't even need nodes.h to be
first, which astonished me initially, but then I realized that both
NodeTag and struct Node are special-cased in gen_node_support.pl,
so we know enough to get by even before reading nodes.h.
More generally, the main *nodes.h files themselves are arranged in
pipeline order, eg parsenodes.h #includes primnodes.h. So that seems
to be a pretty safe thing to rely on even if we grow more cross-header
subtyping cases later. But I'd vote for putting the incidental files
in alphabetical order.
> Second, the order of the files determines the ordering of the output.
> The current order of the files reflects approximately the order how the
> manual code was arranged. That could be changed. We could also just
> sort the node types in the script and dump out everything alphabetically.
+1 for sorting alphabetically. I experimented with that and it's a
really trivial change.
regards, tom lane