[webkit-dev] Unused parameter warnings / errors / warning fixes

Osztrogonác Csaba oszi at inf.u-szeged.hu
Thu Mar 5 06:20:46 PST 2015

Hi again,

it seems opinions are dived about how and what should we do.

I agree that turning on errors for unused parameter for Objective-C
files is undesirable, because we can't omit the parameter name.
Additionally it isn't easy (or maybe it is impossible) to build only
Objective-C sources with -Wno-unused-parameter setting.

I tried to add -Wno-unused-parameter COMPILER_FLAGS to the pbxproj
file for an Objective-C file, but unfortunately -Wall and -Wextra
in WARNING_CFLAGS in *.xcconfig files is stronger, because it is
added later to the compiler argument list.

First and last, I suggest that cmake ports should switch on error
for unused parameters except in WebKit2, where I propose simply
suppressing the warning. This would match the actual Mac settings.

I closed the original bug as wontfixed:

and filed a new bug report for cmake fix:


Osztrogonác Csaba írta:
> I noticed many patches to fix newly introduced unused
> parameter warnings on GTK and EFL ports nowadays.
> (ToT EFL WebKit is warning free right now.)
> CMake ports now handle unused parameters as warnings, not build
> errors everywhere. (-Werror and -Wno-error=unused-parameter )
> Mac port handles them as build errors, except in WebKit, WebKit2
> and WebInspectorUI, where it is disabled (-Wno-unused-parameter)
> WebInspectorUI  is warning free now, but there are zillion warnings
> in WebKit and Webkit2.
> It would be great if we can handle unused parameters in the same way:
> - treat them as errors
> - treat them as warnings and fix sometimes
> - disable them and don't try to fix again and again
>   (and maybe remove zillion UNUSED_PARAM warning fixes )
> I played a little bit to see if it is possible to get rid these warnings
> easily on Mac too and then handle the new ones as build failres:
> https://bugs.webkit.org/show_bug.cgi?id=140764
> But I'm not sure if treating unused parameters as errors would be good
> idea, because many of them depend on different feature ifdef guards
> and it might cause more frequent build failures. Maybe disabling them
> would be better.
> Ideas, opinions, concerns and suggestions are welcome.

More information about the webkit-dev mailing list