| Age | Commit message (Collapse) | Author |
|---|
|
# Conflicts:
# indra/llcommon/CMakeLists.txt
# indra/newview/llspatialpartition.cpp
# indra/newview/llviewergenericmessage.cpp
# indra/newview/llvoavatar.cpp
|
|
using for DRTVWR-559
|
|
ensure inventory skeleton loading doesn't block the message system from processing packets.
|
|
We define a specialization of LLSDParam<const char*> to support passing an
LLSD object to a const char* function parameter. Needless to remark, passing
object.asString().c_str() would be Bad: destroying the temporary std::string
returned by asString() would immediately invalidate the pointer returned by
its c_str(). But when you pass LLSDParam<const char*>(object) as the
parameter, that specialization itself stores the std::string so the c_str()
pointer remains valid as long as the LLSDParam object does.
Then there's LLSDParam<LLSD>, used when we don't have the parameter type
available to select the LLSDParam specialization. LLSDParam<LLSD> defines a
templated conversion operator T() that constructs an LLSDParam<T> to provide
the actual parameter value. So far, so good.
The trouble was with the implementation of LLSDParam<LLSD>: it constructed a
_temporary_ LLSDParam<T>, implicitly called its operator T() and immediately
destroyed it. Destroying LLSDParam<const char*> destroyed its stored string,
thus invalidating the c_str() pointer before the target function was entered.
Instead, make LLSDParam<LLSD>::operator T() capture each LLSDParam<T> it
constructs, extending its lifespan to the lifespan of the LLSDParam<LLSD>
instance. For this, derive each LLSDParam specialization from LLSDParamBase, a
trivial base class that simply establishes the virtual destructor. We can then
capture any specialization as a pointer to LLSDParamBase.
Also restore LazyEventAPI tests on Mac.
|
|
They do work fine on clang... unblocking the rest of the team during diagnosis.
|
|
|
|
|
|
# Conflicts:
# autobuild.xml
# indra/llcommon/tests/llleap_test.cpp
# indra/newview/viewer_manifest.py
|
|
clang has gotten smart enough to recognize an inline attempt to store to
address zero. Fool it by storing to an address passed as a parameter, and pass
nullptr from a different source file.
|
|
The header file documents that no llrand function should ever return a value
equal to the passed extent, so the one test in llrand_test.cpp that checked
less than or equal to the high end of the range was anomalous.
But changing that to an exclusive range means that we no longer need separate
exclusive range and inclusive range functions. Replace
ensure_in_range_using(), ensure_in_exc_range() and ensure_in_inc_range() with
a grand unified (simplified) ensure_in_range() function.
|
|
It's frustrating and unactionable to have a failing test report merely that
the random value was greater than the specified high end. Okay, so what was
the value? If it's supposed to be less than the high end, did it happen to be
equal? Or was it garbage? We can't reproduce the failure by rerunning!
The new ensure_in_exc_range(), ensure_in_inc_range() mechanism is somewhat
complex because exactly one test allows equality with the high end of the
expected range, where the rest mandate that the function return less than the
high end. If that's a bug in the test -- if every llrand function is supposed
to return less than the high end -- then we could simplify the test logic.
|
|
|
|
looks like pool regularly gets corrupted, try using separate pool
|
|
# Conflicts:
# indra/newview/llinventorymodel.cpp
# indra/newview/llvovolume.cpp
|
|
# Conflicts:
# indra/newview/CMakeLists.txt
# indra/newview/VIEWER_VERSION.txt
# indra/newview/llagent.cpp
# indra/newview/llfloaternewfeaturenotification.cpp
# indra/newview/llinventorybridge.cpp
# indra/newview/llinventorymodel.cpp
# indra/newview/lloutfitgallery.cpp
# indra/newview/llpanelmaininventory.cpp
# indra/newview/llpanelmaininventory.h
# indra/newview/llsidepaneltaskinfo.cpp
# indra/newview/llsidepaneltaskinfo.h
# indra/newview/lltexturectrl.cpp
# indra/newview/lltexturectrl.h
# indra/newview/llviewerinventory.cpp
# indra/newview/llviewerobject.cpp
# indra/newview/llviewertexturelist.cpp
# indra/newview/llviewertexturelist.h
# indra/newview/skins/default/xui/en/floater_new_feature_notification.xml
# indra/newview/skins/default/xui/en/menu_inventory.xml
|
|
Move hexdump() and hexmix() stream formatters to new hexdump.h for potential
use by other tests.
In toPythonUsing() helper function, add a temp file to receive Python script
debug output, and direct debug output to that file. On test failure, dump the
contents of that file to the log.
Give NamedTempFile::peep() an optional target std::ostream; refactor
implementation as peep_via() that accepts a callable to process each text
line. Add operator<<() to stream the contents of a NamedTempFile object to
ostream -- but don't use that with LL_DEBUGS(), as it flattens the file
contents into a single log line. Instead add peep_log(), which streams each
individual text line to LL_DEBUGS().
|
|
|
|
|
|
|
|
A test executable on a GitHub Windows runner failed with C00000FD, which
reports stack overflow.
(cherry picked from commit aab7b4ba3812e5876b1205285bcfd8cff96bcac9)
|
|
Add DEBUG log output to try to diagnose.
|
|
# Conflicts:
# indra/newview/app_settings/settings.xml
# indra/newview/llinventoryfunctions.cpp
# indra/newview/llinventoryfunctions.h
# indra/newview/llinventorymodel.cpp
# indra/newview/llinventoryobserver.cpp
# indra/newview/llinventoryobserver.h
# indra/newview/skins/default/xui/ja/floater_inventory_item_properties.xml
|
|
# Conflicts:
# autobuild.xml
|
|
|
|
For unknown reason allocations of these coroutines often crash on client machines.
1. Limit quantity of coros running in parallel by reducing retries and wait time
2. Print out more diagnostic info
|
|
that unconditionally return. This eliminates the problem of pacifying a
compiler that expects a return statement vs. a compiler that detects that
callFail() unconditionally throws.
Thanks, Ansariel.
|
|
|
|
LLSDParam<LLSD> is the generic case, when we need to pass LLSDParam adapters
to some set of function parameters whose types we don't specifically know. Its
templated conversion operator notices the actual parameter type T and
delegates conversion to the specific LLSDParam<T> specialization.
But when T has picked up references, e.g. somewhere along the way in the
LL::apply() machinery, the compiler might not choose the desired conversion
because we don't have a sufficiently specific LLSDParam specialization.
LLSDParam<LLSD> can address that by using std::decay_t<T> when delegating to
the specific LLSDParam specialization. This removes references, const and
volatile.
|
|
There's a limit to how much time it's worth trying to work around a compiler
bug that's already been fixed in newer Xcode.
|
|
|
|
|
|
That wasn't the issue. This is a compiler bug:
https://github.com/llvm/llvm-project/issues/41999
https://stackoverflow.com/q/57080425
https://bugs.llvm.org/show_bug.cgi?id=42654
This reverts commit c406fa7ae97441d1d6e0ea6727c42c8f978fabed.
|
|
|
|
Both the previous version and this compile and run successfully with Xcode
14.3.1, but our older TeamCity compiler chokes -- so we must iterate remotely,
sigh.
|
|
VC doesn't recognize that a constexpr name doesn't need to be bound into a
lambda. However, since it's knowable at compile time, it can be deduced within
the innermost lambda.
(cherry picked from commit 37c3daff1a565eaafee691dfb57702b6b8f024d6)
|
|
|
|
|
|
|
|
Major improvements to LLLeap functionality
|
|
LL_USE_SYSTEM_RAND has been disabled since June 2008; that code only clutters
the implementation we actually use.
|
|
|
|
|
|
# Conflicts:
# indra/llui/llfolderviewitem.cpp
# indra/newview/llinventorymodel.cpp
# indra/newview/llinventorymodelbackgroundfetch.cpp
|
|
|
|
# Conflicts:
# doc/contributions.txt
# indra/llcommon/llerrorthread.cpp
|
|
|
|
Once std::apply() becomes available, 'using std::apply;' isn't correct because
the more general template tries to handle the apply(function, vector) case
that we explicitly implement below. Have to provide apply(function, tuple) and
apply(function, array) signatures that can forward to std::apply().
|
|
|
|
(cherry picked from commit 2c1253c8ed2a1648317e6edd768b3fda00c56ce2)
|
|
addMethod() was using dynamic_cast<target class*>(this) and testing for
nullptr to decide whether the class owning the passed method is, or is not, a
subclass of LLEventDispatcher. The trouble is that it doesn't work for the
deferred add() calls queued by LazyEventAPI: the dynamic_cast was always
returning nullptr. static_cast works better, but that leaves us with the
problem we were trying to solve with dynamic_cast: what if the target class
really isn't a subclass? Use std::is_base_of to pick which of two addMethod()
overloads to invoke, one of which calls addFail().
(cherry picked from commit a4d520aa5d023d80cfeec4f40c3464b54cbcfc5b)
|
