Re: [PATCH] build: Silence clang warning on older glib autoptr usage

[Eric Blake]

On 3/17/20 1:11 PM, Peter Maydell wrote:
> On Tue, 17 Mar 2020 at 17:55, Eric Blake <address@hidden> wrote:
> > glib's G_DEFINE_AUTOPTR_CLEANUP_FUNC() macro defines several static
> > inline functions, often with some of them unused, but prior to 2.57.2
> > did not mark the functions as such.  As a result, clang (but not gcc)
> > fails to build with older glib unless -Wno-unused-function is enabled.
> >
> > Reported-by: Peter Maydell <address@hidden>
> > Signed-off-by: Eric Blake <address@hidden>
> > ---
> >
> > Half-tested: I proved to myself that this does NOT enable
> > -Wno-unused-function on my setup of glib 2.62.5 and gcc 9.2.1 (Fedora
> > 31), but would do so if I introduced an intentional compile error into
> > the sample program; but Iwas unable to test that it would prevent the
> > build failure encountered by Peter on John's pull request (older glib
> > but exact version unknown, clang, on NetBSD).
>
> This wasn't a NetBSD failure. I hit it on my clang-on-x86-64-Ubuntu
> setup, and also on FreeBSD. (The latter is just the tests/vm
> FreeBSD config, so you can repro that if you need to.)
>
> The ubuntu setup is libglib 2.56.4-0ubuntu0.18.04.4 and
> clang 6.0.0-1ubuntu2.

Thanks; I ran:

$ make docker-test-clang@ubuntu1804 DEBUG=1
...
bash-4.4$ cat > foo.c <<\EOF
> #include <glib.h>
> typedef struct Foo {
>     int i;
> } Foo;
> static void foo_free(Foo *f)
> {
>     g_free(f);
> }
> G_DEFINE_AUTOPTR_CLEANUP_FUNC(Foo, foo_free);
> int main(void) { return 0; }
> EOF
bash-4.4$ clang -Wall -Werror $(pkg-config --cflags gmodule-2.0) \
  -o foo -c foo.c
...
glib_slistautoptr_cleanup_Foo
^
3 errors generated.
bash-4.4$ clang -Wall -Werror $(pkg-config --cflags gmodule-2.0) \
  -o foo -c foo.c -Wno-unused-function
bash-4.4$

to confirm that my test snippet does flush out the error in question. 
However, removing DEBUG=1 takes a long time to run (hmm, maybe I should 
set TARGET_LIST to speed it up), and did not reproduce the failure for 
me without the patch (making it hard to tell if the patch made a 
difference).  I'm still playing with testing, but at least I feel better 
that this patch is on the right track, now that I have an environment 
that can reproduce the situation.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org