Age | Commit message (Collapse) | Author |
|
|
|
|
|
# Conflicts:
# indra/newview/llfloatermodelpreview.cpp
|
|
|
|
# Conflicts:
# indra/newview/llfloaterbuycurrency.cpp
# indra/newview/llinventorybridge.cpp
# indra/newview/llinventorypanel.h
# indra/newview/skins/default/xui/en/floater_buy_currency.xml
|
|
|
|
|
|
# Conflicts:
# doc/contributions.txt
# indra/newview/llfloaterconversationpreview.cpp
# indra/newview/llinventorypanel.h
# indra/newview/llmeshrepository.h
# indra/newview/llvoicevivox.cpp
|
|
|
|
This reverts commit 92499ce1b43fd60ce7aad71d12f9eef0cef04f7f.
# Conflicts:
# indra/newview/llinventorybridge.cpp
# indra/newview/llinventorypanel.cpp
# indra/newview/llinventorypanel.h
|
|
# Conflicts:
# indra/newview/llinventorybridge.cpp
# indra/newview/llinventorypanel.cpp
|
|
Callstack is clearly broken since it points to LLNotifications::instance().clear(); after 'Goodbye!', my suspicion is that something reinitialized singleton so I fixed cleanup and added some logging to see if there is a dupplicate init
|
|
|
|
|
|
# Conflicts:
# indra/cmake/DirectX.cmake
# indra/newview/llviewerparcelmedia.cpp
# indra/newview/viewer_manifest.py
|
|
|
|
Get rid of that ugly '#pragma clang diagnostic ignored "-Wdelete-incomplete"' by making sure the delete always happens inside llview.cpp, where the type of LLView is known.
|
|
This is not correct, as clang is available on all 3 platforms. The correct way to check for this is via __clang__ (https://clang.llvm.org/docs/LanguageExtensions.html#builtin-macros)
|
|
# Conflicts:
# autobuild.xml
|
|
# Conflicts:
# autobuild.xml
# indra/newview/llimprocessing.cpp
|
|
# Conflicts:
# indra/llcommon/llkeybind.cpp
# indra/llcommon/llkeybind.h
|
|
Changes were moved to DRTVWR-514
|
|
"SpellCheck" is FALSE
|
|
|
|
|
|
|
|
# Conflicts:
# indra/llxml/llcontrolgroupreader.h
# indra/newview/llviewerkeyboard.cpp
|
|
|
|
|
|
|
|
|
|
|
|
# Conflicts:
# indra/newview/llinventorybridge.cpp
# indra/newview/llinventorypanel.cpp
# indra/newview/lltexturectrl.cpp
# indra/newview/skins/default/xui/de/floater_texture_ctrl.xml
# indra/newview/skins/default/xui/es/floater_texture_ctrl.xml
# indra/newview/skins/default/xui/fr/floater_texture_ctrl.xml
# indra/newview/skins/default/xui/it/floater_texture_ctrl.xml
# indra/newview/skins/default/xui/ja/floater_texture_ctrl.xml
# indra/newview/skins/default/xui/pt/floater_texture_ctrl.xml
# indra/newview/skins/default/xui/ru/floater_texture_ctrl.xml
# indra/newview/skins/default/xui/tr/floater_texture_ctrl.xml
# indra/newview/skins/default/xui/zh/floater_texture_ctrl.xml
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Conflicts:
# indra/llmath/llquaternion.h
# indra/newview/lldrawpoolwater.cpp
# indra/newview/lljoystickbutton.cpp
# indra/newview/llvosky.cpp
# indra/newview/skins/default/textures/textures.xml
|
|
|
|
# Conflicts:
# indra/newview/app_settings/shaders/class1/objects/previewV.glsl
# indra/newview/lldynamictexture.cpp
# indra/newview/llfloatermodelpreview.cpp
|
|
# Conflicts:
# indra/newview/pipeline.cpp
|
|
|
|
|
|
|
|
|
|
LLEventDetail::visit_and_connect() promised special treatment for the
specific case when an LLEventPump::listen() listener was composed of (possibly
nested) boost::bind() objects storing boost::weak_ptr values -- specifically
boost::bind() rather than std::bind or lambdas, specifically boost::weak_ptr
rather than std::weak_ptr.
Outside of self-tests, it does not appear that anyone actually uses that
support.
There is good reason not to: it's a silent side effect of a complicated
compile-time inspection that could be silently derailed by use of std::bind()
or a lambda or a std::weak_ptr. Can you be sure you've engaged that promise?
How?
A more robust guarantee can be achieved by storing an LLTempBoundConnection in
the transient object itself. When the object is destroyed, the listener is
disconnected. Normal C++ rules around object destruction guarantee it. This
idiom is widely used.
There are a couple good reasons to remove the visit_and_connect() machinery:
* boost::bind() and boost::weak_ptr do not constitute the wave of the future.
Preferring those constructs to lambdas and std::weak_ptr penalizes new code,
whether by silently failing or by discouraging use of modern idioms.
* The visit_and_connect() machinery was always complicated, and apparently
never very robust. Most of its promised features have been commented out
over the years. Making the code base simpler, clearer and more maintainable
is always a useful effect.
LLEventDetail::visit_and_connect() was also used by the four
LLNotificationChannelBase::connectMumble() methods. Streamline those as well.
Of course, remove related test code.
|
|
|