Peter Eisentraut <peter.eisentr...@enterprisedb.com> writes: > On 11.07.22 01:09, Tom Lane wrote: >> Andres Freund <and...@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