Usage of LazyInstance to avoid static initializers can be replaced with constexpr initialization for trivially constructible types :)
On top of being cleaner, this mitigates issues like crbug.com/797129 :)
Did a survey of base:: types (and their usage in LazyInstances) :
Can be made constexpr easily (https://chromium-review.googlesource.com/c/chromium/src/+/860157):
android::ScopedJavaGlobalRef
circular_deque
PlatformThreadHandle
PlatformThreadRef
scoped_nsobject
scoped_refptr
subtle::SpinLock
TestDiscardableMemoryAllocator
Time
TimeTicks (already is but still has LazyInstances around)
VectorBuffer
Should work but getting weird Clang errors about inline constructor which isn't inline?
(Once|Repeating)?(Callback|Closure)
PartitionAllocatorGeneric
SizeSpecificPartitionAllocator
With some work:
ThreadLocalStorage::Slot
ThreadLocalBoolean
ThreadLocalPointer
SequenceChecker (tricky -- need to avoid use of Lock)
AtomicFlag (depends on SequenceChecker)
WeakPtr (depends on SequenceChecker)
ObserverList (depends on WeakPtr)
ThreadChecker
Don't think so:
android::ApplicationStatusListener
internal::LazySysInfoValue
Lock
Depends on std:
FilePath (std::string)
hash_map (std::unordered_map)
hash_set (std::unordered_set)
IDMap
queue
stack
string16
Thread (std::string)
Need to be careful with no adding more static uninitializers by replacing LazyInstance::Leaky's with constexpr variables.
I'm planning to go with step #1 of proposal @ crbug.com/800808 to mitigate that : always terminate process at end of main :).
There are also instances where DestructorAtExit is useful to clean up state between unit tests (leaking in prod is fine).
(Available : no longer actively working on this)
Comment 1 by gab@chromium.org
, Jan 10 2018