Currently, if there is space between an identifier and a :: operator in the original code, that space is kept in case the identifier is a macro that isn't part of the following nested name specifier. The issue is for the identifiers that are part of the nested name specifier.
I tried to find an heuristic to determine if a :: operator was a global specifier, but that is impossible with only syntactical analysis. Instead, I went for a solution creating a option containing all the macro identifiers that shouldn't not be merge to the following nested name specifier. Usually, those macros are hiding keywords (and attributes) so I called the option KeywordMacros but it might be a bad name. If an identifier is not listed in that list, it is assumed that it is part of the following nested name specifier and merged with it.
It's still a work in progress. Function declaration like this
seems to be legal (but not if the return type has a nested name specifier), but it's not handled by my change. I tried checking if the line is MightBeFunctionDecl and the identifier is the first token of the line but that doesn't work.
This patch fixes bug #44189