[RFC] Defined initialization order in Support/Registry

Project Infrastructure LLVM Dev List Archives
1

Dear List,

First things first, this is based off a bug report and a (less than
ideal) patch by yours truly:
https://github.com/clangd/clangd/issues/578
https://reviews.llvm.org/D91351

Currently Plugins appear in the Registry linked list in an undefined
order due to the 'static initialization order fiasco'.
For most registries this doesn't pose a problem as there is no
observable difference in behaviour, however for a select few there is.

In the aforementioned patch this was addressed by explicity giving the
plugins a relative order and sorting them based on that. This, while it
does serve the purpose, wont help if any other registries may need to
adopt similar behaviour and requires collecting all the available
plugins, sorting them and finally iterating over them.

What I propose is an extra optional argument on the `Add` method that
can specify a relative ordering of plugins in the case when the order
is important. Plugins with a lower order will appear in the linked list
first and plugins that don't use the extra argument will after all
plugins that do use it. If there are multiple plugins in a registry not
using the argument it will follow the same 'static initialization order
fiasco' that is currently observed.

I have created a basic implementation of this along with tests here
⚙ D91454 [llvm] Enable specifying the order of Registry entries.

As the extra parameter is optional it will remain backwards compatible
with source code, but external plugins would need to be recompiled to
adopt this (though thats usually the case with every major release)

Thanks for reading,
Nathan James

2

Any chance of this not using a plugin registration system like this at
all? (I guess such a registration system has some complications in the
linker model (these registration devices can't go into static
archives, or they'll fail to be linked in, since they're otherwise
unreferenced, right?) that might be better addressed by an explicit
dependency?)

I realize this'd probably be awkward for consumers that want to add
their own providers in without modifying the original source code -
either they could put up with modifying the code, or they could write
their own driver, using LLVM as a library? (I'd be in favor of any
refactoring that'd make that easier - keeping as much code reuse as
possible)