[llvm-dev] [RFC] Defined initialization order in Support/Registry

[David Blaikie via llvm-dev]

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)

On Fri, Nov 13, 2020 at 12:24 PM Nathan James via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> 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
> https://reviews.llvm.org/D91454.
>
> 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
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev