1903830 - Add lint to deny new uses of compiler_metrics num_static_constructors. Hint to use StaticAutoPtr instead

Status: NEW

(Developer Infrastructure :: Source Code Analysis, enhancement)

Description

[Manuel Bucher [:manuel]]

It looks like an anti-pattern to use static variables (for non-fundamental types)? It looks statically lintable to me.

It would be great if caught during automatic review in phabricator.

Bug that caused a regression: https://bugzilla.mozilla.org/buglist.cgi?quicksearch=ALL+num_static_constructors, bug_id list

There are a lot closed as WONTFIX in there, likely due to lack of documentation & late discovery.

Doc on what should be used instead:

https://searchfox.org/mozilla-central/rev/74518d4f6979b088e28405ba7e6238f4707639cf/xpcom/base/StaticPtr.h#17-32

/**
 * StaticAutoPtr and StaticRefPtr are like UniquePtr and RefPtr, except they
 * are suitable for use as global variables.
 *
 * In particular, a global instance of Static{Auto,Ref}Ptr doesn't cause the
 * compiler to emit a static initializer.
 *
 * Since the compiler guarantees that all global variables are initialized to
 * 0, the default constexpr constructors will result in no actual code being
 * generated. Since we rely on this, the clang plugin, run as part of our
 * "static analysis" builds, makes it a compile-time error to use
 * Static{Auto,Ref}Ptr as anything except a global variable.
 *
 * Static{Auto,Ref}Ptr have a limited interface as compared to ns{Auto,Ref}Ptr;
 * this is intentional, since their range of acceptable uses is smaller.
 */

Filing after investigations on Bug 1903713.