Maybe we could do that with the searchfox db...

Searchfox uses a clang plugin to get its knowledge about C++ code. Instead of trying to shoehorn it into searchfox it would be better to just write a new clang plugin.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #14)

Searchfox uses a clang plugin to get its knowledge about C++ code. Instead of trying to shoehorn it into searchfox it would be better to just write a new clang plugin.

What Sylvestre meant is to use the data produced by the searchfox Clang Plugin, not putting it into searchfox. I think a new Clang plugin wouldn't save a lot, you would still have to generate all the data, then postprocess it (because you have to scan for other invocations of the function, which you can't do directly from the Clang plugin).

I don't know if the searchfox data has all the information available for this, but I can take a look at it next week maybe.

clang's -Wmissing-prototypes option can identify some global functions that can be made static (or removed if they are unused).

-Wmissing-prototypes warns about global functions definitions that have no previous function prototype (e.g. from a header file) in scope. These functions could be made static (e.g. bug 1443402) because they are probably not called by other compilation units. Without a function prototype in a header file, another compilation unit would need to declare its own prototype for the function or use some dynamic mechanism like dlsym().

https://clang.llvm.org/docs/DiagnosticsReference.html#wmissing-prototypes

Unfortunately, there are currently 1331 -Wmissing-prototypes warnings, so fixing them all is probably impractical. Also, these warnings would not catch global functions that do have a function prototype but are still only called from one compilation unit (or not called at all).

Confusingly, gcc's -Wmissing-prototypes option is not equivalent to clang's -Wmissing-prototypes. -Wmissing-declarations is gcc's name for clang's -Wmissing-prototypes.

https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Warning-Options.html

(In reply to Christian Holler (:decoder) from comment #15)

What Sylvestre meant is to use the data produced by the searchfox Clang Plugin, not putting it into searchfox. I think a new Clang plugin wouldn't save a lot, you would still have to generate all the data, then postprocess it (because you have to scan for other invocations of the function, which you can't do directly from the Clang plugin).

I don't know if the searchfox data has all the information available for this, but I can take a look at it next week maybe.

Ah I see. The goals of searchfox and this bug still seem fundamentally different to me, so I'm not sure code sharing is such a good idea. Feel free to fork the searchfox clang-plugin though. If you do reuse the code as-is keep in mind the output format is subject to change at any time, no guarantees provided etc. Also the searchfox jobs currently only run on {mac,linux,windows}-debug builds so they might miss stuff.

Is this patch good to go? If not, can it be updated?