> On Jan 26, 2015, at 10:18 AM, Darin Adler <da...@apple.com> wrote: > > On Jan 26, 2015, at 10:11 AM, Filip Pizlo <fpi...@apple.com> wrote: > >> So I actually do the opposite of pushing the configuration conditionals to >> the edges - I put them into the innards. > > Yes, this explains why the unused argument warnings are so frustrating for > you!
Not just for me. And I don’t think it explains that at all. Platform and configuration conditionals imply that somewhere, there will have a method body that has #ifdefs that guard a call (or field access) to conditionalized code - otherwise that conditionalized code would never get called. I suspect we all try to minimize the total pain of #ifdefs. In some code, you get the smallest total pain by placing the #ifdefs on the edges; in other code it works best in the innards. There are many examples of the former. CPU guards are one example of the latter: - Methods providing access to CPU features that are only available through inline assembly will be unconditionally declared but will have conditionalized innards. - Most of the JIT treats hardware abstractly, and we try to isolate the places where CPU guards take effect. This means that the innards of methods that deal with things like calling convention will have conditionals. I don’t mean to advocate the innards strategy as a general one - my point is that if your goal is to reduce total pain from #ifdefs and UNUSED_PARAMs then you will sometimes use the innards strategy. > > I don’t know what it says for the project as a whole. Whether we place #ifdefs on the edges or in the innards doesn’t have much impact on whether or not we get unused parameter warnings. I believe that JavaScriptCore errs on the innards strategy and it has 169 UNUSED_PARAM lines. I suspect that WebCore doesn’t use this strategy as much, and it has 1679 UNUSED_PARAM lines. This implies that WebCore has a higher UNUSED_PARAM line rate than JavaScriptCore. JavaScriptCore is, by my crude count (using the same file finding script that I used for the UNUSED_PARAM grep), 323198 lines of code while WebCore is 1012440. This means that a JavaScriptCore file will have an UNUSED_PARAM line at a rate of 523 per one million lines of code, while WebCore will have an UNUSED_PARAM line at a rate of 1658 per one million. I believe that JavaScriptCore and WebCore use different strategies for dealing with conditionalized code. WebCore seems to be more likely to do what you suggest. This does not seem to decrease the amount of noise due to unused parameters. -Filip _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
