TL;DR:Please rebase all your (existing and future) master Gerrit changes atop current master, containing that above commit "Avoid infinite loops in loplugin".
======Starting sometime in the last 24 hours, Jenkins builds of Gerrit master changes (specifically the linux_clang_dbgutil_64 among the four builds) started to hang, causing the "Gerrit Build v2" queue at <https://ci.libreoffice.org/> to grow forever.
I think I've fixed my mistake that caused that now with <https://cgit.freedesktop.org/libreoffice/core/commit/?id=49027122436dc061768e1e781d36755ff041d4a9> "Avoid infinite loops in loplugin" now. (It was an infinite loop that could now happen in loplugin. Unfortunately, it apparently only happens with some old Clang versions, so it didn't happen for me locally when introducing the mistake. Double unfortunately, for performance reasons that loplugin-enabled Gerrit Jenkins bot does not invalidate its ccache when loplugin changes, so it happened to not actually recompile any of the problematic sources against the changed loplugin when I handed to Gerrit for verification that change introducing the mistake. Things only started to go south later, when some unsuspecting other Gerrit change caused actual rebuild of such a source file.)
I have killed all outstanding Gerrit Jenkins builds a moment ago. (And might have accidentally killed one or the other unrelated Jenkins build, too. That web UI is really hard to use there.)
What, triple unfortunately, caused this to wreck even more havoc is that Jenkins apparently doesn't automatically kill builds that don't progress. It would be greatly appreciated if somebody in charge of that Jenkins installation could look into that. (If, for testing purposes, you need a way to get a compiler invocation to hang during the build, I can help you out with that.)
Really sorry for the inconveniences... Stephan