near the end of LLAppViewer::cleanup() so every LLSingleton class that hasn't
already been explicitly cleaned up gets a chance to perform its own cleanup.
Specifically, log as LLSingleton captures inter-Singleton dependencies. Also
log cleanupAll() calls to cleanupSingleton() and deleteAll() calls to
deleteSingleton(), since they happen in an implicitly-determined order. But do
not log anything during the implicit LLSingletonBase::deleteAll() call
triggered by the runtime destroying the last LLSingleton's static data. That's
too late in the run; even std::cerr might already have been destroyed!
Introduce corresponding llcleanup.cpp, llinitdestroyclass.cpp modules to
contain code that performs logging calls.
Track class::method names for LLInitClass<T> and LLDestroyClass<T> subclasses,
and log them when called. The order in which these calls occur could be
relevant to bugs, and could surface the need to convert to LLSingleton
dependencies.
It used to contain an LLSingleton called Singleton, requiring
LLGlobalEconomy::Singleton::instance() to access it rather than the
conventional LLGlobalEconomy::instance(). This has been fixed, so normalize
references accordingly.
LLSingleton::getIfExists() has been eliminated. The only remaining way to
detect whether a given LLSingleton has been instantiated is to call
instanceExists(). But the relevant cleanup code should be refactored to
cleanupSingleton() anyway, which would make this specific call moot.
clang gets nervous about expressions that call functions inside typeid(), even
though these particular typeid() calls are runtime expressions on runtime
values. Extract the offending calls to a previous statement.
This particular test relied on there being exactly one instance of the string
"indra" in the source file's __FILE__ path -- which is usually true, but not
if the developer clones the viewer source repo under a parent directory whose
path itself contains "indra". Fix to handle any number of occurrences.
This means that an exception derived from LLContinueError thrown in an
LLEventPump listener won't prevent other listeners on the same LLEventPump
from receiving that event.
SL-10043 FIXED Viewer crashes when double-clicking 'For sale' parcel icon on World map in some cases
Approved-by: Andrey Lihatskiy <andreylproductengine@lindenlab.com>
Approved-by: Andrey Kleshchev <andreykproductengine@lindenlab.com>
LLView::childFromPoint(), which is declared to return LLView*, contained a
code path that could 'return false'. This is blatantly wrong. Why has it
compiled on our other compilers so far?
AndreyL ProductEngine