Bug 1800717

This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle.
Changing version to 32.

Interestingly, the same problem is observed with

> gcc (GCC) 8.2.1 20180905 (Red Hat 8.2.1-3)
> gcc (GCC) 8.3.1 20191121 (Red Hat 8.3.1-5)

Note sure which compiler, gcc or clang, is correct here, and which
is not (both cannot be at the same time when they exhibit contradicting
behaviours, unless there's some explicit compiler-sensitive
conditionalizing, right?).

May as well be the case that clang + glib2 are wrong concurrently.

Just look at the definition of the macro, it is compiler and even compiler version specific, furthermore uses compiler specific pragmas.

Furthermore, I don't understand what you are complaining about, when you are compiling with -Werror, you request all the warnings to be promoted to errors and it is up to you to either fix those or disable.
From the #c0 output, it seems clang warns as well about those, so either you aren't compiling with -Werror when using clang, or clang can't handle -Werror in the preprocessor, or there are pragmas to downgrade these warnings to just warnings rather than errors.

-Werror has (should not have) anything to do with this.
I see it casts some confusion, but that wasn't intended.
I don't think it would have any bearing on the effect I have
in mind.

The gist is, as per summary, that the trailing token (here
"g_main_loop_new" per what clang produces for the first occurrence)
is missing in the deprecation warning message when building with GCC.

As mentioned, might be the problem with GLib2 that it doesn't do
this messaging properly (plus that clang copes with that properly
anyway?) instead.  Not an expert, still could try to minimize the
scenario if it's asked.

The most descriptive line in GLib's code:
https://gitlab.gnome.org/GNOME/glib/blob/91cb1710574309b4c52b388bb5cc7a4e899050bc/glib/gmacros.h#L990

The question is: why does #f part resolve to empty string, when
it resolves to input argument with clang?

Still reproducible with gcc-11.0.0-0.18.fc34.x86_64 and
glib2-devel-2.67.3-2.fc34.x86_64.

As I got confused myself, to demonstrate reality vs. expected clearly:

-sbd-pacemaker.c:565:20: error: Deprecated pre-processor symbol, replace with  [-Werror]
+sbd-pacemaker.c:565:20: error: Deprecated pre-processor symbol, replace with g_main_loop_new [-Werror]
   565 |         mainloop = g_main_new(FALSE);
       |                    ^~~~~~~~~~~~~~~~~~

That looks clearly like a glib2 bug.
As can be seen in:
#define G_STRINGIFY(macro_or_string)    G_STRINGIFY_ARG (macro_or_string)
#define G_STRINGIFY_ARG(contents)       #contents
#define _GLIB_GNUC_DO_PRAGMA(x) _Pragma(G_STRINGIFY (x))
#define GLIB_DEPRECATED_MACRO_FOR(f) _GLIB_GNUC_DO_PRAGMA(GCC warning "Deprecated pre-processor symbol, replace with" #f)

#define FOO GLIB_DEPRECATED_MACRO_FOR(foo)
FOO

#define GLIB_DEPRECATED_MACRO_FOR2(f) _GLIB_GNUC_DO_PRAGMA(GCC warning G_STRINGIFY(Deprecated pre-processor symbol; replace with f))
#define BAR GLIB_DEPRECATED_MACRO_FOR2(foo)
BAR

#pragma GCC warning "Deprecated pre-processor symbol, replace with" "foo"
#pragma GCC warning "Deprecated pre-processor symbol, replace with foo"

- #pragma GCC warning expects a single argument.  Pragma processing is during translation phase 4,
while adjacent string literal concatenation is later (translation phase 6), plus GCC warning is an extension,
so I don't see anything wrong with that.

So, IMHO glib2 should replace (at least for GCC its GLIB_DEPRECATED_MACRO_FOR macro with something like my
GLIB_DEPRECATED_MACRO_FOR2 above (note, what it has currently even if the concatenation worked, it lacks a space after with).
Getting a comma into it would be harder, but can be done too, just don't have time to do that now.
And similarly GLIB_UNAVAILABLE_MACRO needs fixing too.

If you want comma, you can do:
#define G_STRINGIFY_VA(...)    G_STRINGIFY_ARG_VA (__VA_ARGS__)
#define G_STRINGIFY_ARG_VA(...)       #__VA_ARGS__
#define GLIB_DEPRECATED_MACRO_FOR(f) _GLIB_GNUC_DO_PRAGMA(GCC warning G_STRINGIFY_VA(Deprecated pre-processor symbol, replace with f))
#define BAR GLIB_DEPRECATED_MACRO_FOR(foo)
BAR

Thanks for looking into this.  I am confused about the culprit, indeed.
That Clang behaved as expected may have not helped in this confusion.

Thanks for the suggestions. But it is already fixed by https://gitlab.gnome.org/GNOME/glib/-/commit/52ad3ed7171f11da141eea32813e0d85f2fac4fb.