GNOME Bugzilla – Bug 710869
Disable some GCC warnings for generated C code
Last modified: 2013-10-25 18:19:15 UTC
The GCC warning spew which results from Vala’s non-perfect generated C code is really starting to irritate me. Patch coming which adds some #pragmas to disable as many of these warnings as possible. Unfortunately some of the warnings are for const qualifier discards and passing parameters of the wrong type, which (as far as I know) can’t be disabled. I’ve filed several Vala bugs to try and get those fixed. In any case, this patch improves the situation for several areas of folks’ code base, entirely eliminating warnings for several C files.
Created attachment 258095 [details] [review] build: Disable some GCC warnings for generated C code The GCC warning spew which results from Vala’s non-perfect generated C code is distracting and can mask genuine warnings from valac or GCC. This patch adds some #pragmas in warnings.h which disable as many of these warnings as possible. Unfortunately some of the warnings are for const qualifier discards and passing parameters of the wrong type, which (as far as I know) can’t be disabled. In any case, this patch eliminates GCC warnings for several C files, which is better than nothing. Note that warnings.h should only be included in build targets which compile only Vala, and don’t compile any non-generated C code. Non-generated C code should always be compiled with all warnings enabled, to catch legitimate errors. See the comment at the top of warnings.h.
Created attachment 258096 [details] [review] build: Disable some GCC warnings for generated C code The GCC warning spew which results from Vala’s non-perfect generated C code is distracting and can mask genuine warnings from valac or GCC. This patch adds some #pragmas in warnings.h which disable as many of these warnings as possible. Unfortunately some of the warnings are for const qualifier discards and passing parameters of the wrong type, which (as far as I know) can’t be disabled. In any case, this patch eliminates GCC warnings for several C files, which is better than nothing. Note that warnings.h should only be included in build targets which compile only Vala, and don’t compile any non-generated C code. Non-generated C code should always be compiled with all warnings enabled, to catch legitimate errors. See the comment at the top of warnings.h.
(Second version of the patch added a NEWS entry.) Note that this includes changes for the BlueZ backend, which hasn’t been merged yet (bug #685848). I can easily rebase to remove those changes if this gets reviewed first.
Review of attachment 258096 [details] [review]: With what I checked out, this looks like a nice improvement. It really would be nice to whittle down the listed bugs in Vala because those warnings still take up a fair amount of our output. It'd also be nice to massively summarize the valadoc (bug #710886) and install step (bug #710887) output, but I've filed those bugs to track that. If you commit this before the BlueZ backend, just move that portion into the BlueZ backend branch while it's in progress.
Comment on attachment 258096 [details] [review] build: Disable some GCC warnings for generated C code Committed without the BlueZ changes. commit ec466f400d79e58ac655919bf7c3047909c4aecd Author: Philip Withnall <philip.withnall@collabora.co.uk> Date: Fri Oct 25 11:50:31 2013 +0100 build: Disable some GCC warnings for generated C code The GCC warning spew which results from Vala’s non-perfect generated C code is distracting and can mask genuine warnings from valac or GCC. This patch adds some #pragmas in warnings.h which disable as many of these warnings as possible. Unfortunately some of the warnings are for const qualifier discards and passing parameters of the wrong type, which (as far as I know) can’t be disabled. In any case, this patch eliminates GCC warnings for several C files, which is better than nothing. Note that warnings.h should only be included in build targets which compile only Vala, and don’t compile any non-generated C code. Non-generated C code should always be compiled with all warnings enabled, to catch legitimate errors. See the comment at the top of warnings.h. https://bugzilla.gnome.org/show_bug.cgi?id=710869 NEWS | 1 + backends/eds/Makefile.am | 1 + backends/eds/lib/Makefile.am | 5 ++++ backends/key-file/Makefile.am | 1 + backends/libsocialweb/Makefile.am | 1 + backends/libsocialweb/lib/Makefile.am | 5 ++++ backends/ofono/Makefile.am | 1 + backends/telepathy/Makefile.am | 1 + backends/telepathy/lib/Makefile.am | 6 +++++ backends/tracker/Makefile.am | 1 + backends/tracker/lib/Makefile.am | 1 + folks/Makefile.am | 11 ++++++++ folks/warnings.h | 85 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ tests/eds/Makefile.am | 1 + tests/folks/Makefile.am | 1 + tests/key-file/Makefile.am | 1 + tests/lib/eds/Makefile.am | 5 ++++ tests/lib/key-file/Makefile.am | 5 ++++ tests/lib/libsocialweb/Makefile.am | 5 ++++ tests/lib/telepathy/Makefile.am | 5 ++++ tests/lib/tracker/Makefile.am | 5 ++++ tests/libsocialweb/Makefile.am | 1 + tests/telepathy/Makefile.am | 1 + tests/tracker/Makefile.am | 1 + tools/Makefile.am | 1 + tools/inspect/Makefile.am | 1 + 26 files changed, 153 insertions(+)
Aaaand a bonus! commit 18c629cf1d40a72c5f9f04a31dbdf4a265306cd9 Author: Philip Withnall <philip.withnall@collabora.co.uk> Date: Fri Oct 25 18:09:50 2013 +0100 build: Enable colourised output from GCC If GCC supports it, enable the -fdiagnostics-color=auto option, which adds colour to warnings and errors outputted by GCC. Enable this for both generated and non-generated C code. https://bugzilla.gnome.org/show_bug.cgi?id=710869 configure.ac | 4 ++++ 1 file changed, 4 insertions(+)
Shouldn't you put those under a #ifdef __GNUC__ ? What happens if you build this with another compiler than gcc? like llvm for example?
(In reply to comment #7) > Shouldn't you put those under a #ifdef __GNUC__ ? What happens if you build > this with another compiler than gcc? like llvm for example? http://clang.llvm.org/docs/UsersManual.html#controlling-diagnostics-via-pragmas For any other compilers, we can fix the problems if they arise. I don’t have access to any other compilers to test with.