| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
# Conflicts:
# autobuild.xml
|
|
following promotion of DRTVWR-582
|
|
Looks like a bit of code from Inventory Extensions viewer leaked into
release. This was supposed to prevent 'folder does not exist' spam as
Inventory Extensions does not create folders this way, instead it
blocked folder creation.
|
|
|
|
|
|
Privileged
|
|
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)
|
|
|
|
|
|
|
|
|
|
|
|
Replace deprecated event mask call (macOS)
|
|
replacement NSEventMaskAny. Functionality unaltered.
|
|
simulator
|
|
Major improvements to LLLeap functionality
|
|
DRTVWR-577 (#232)
|
|
|
|
INTL-490 Japanese Translation Update
|
|
|
|
|
|
# Conflicts:
# doc/contributions.txt
# indra/llcommon/llerrorthread.cpp
|
|
following promotion of DRTVWR-580
|
|
|
|
|
|
|
|
|
|
This happens when a calling card is created before the name is in the
name cache.
|
|
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)
|
|
std::get<I>(const tuple) injects const into the type of each returned tuple
element. Need to get a non-const ref to the tuple param to get the true type.
(cherry picked from commit 6dda39065d3ee231998cb8a2896f94e8a45c9a82)
|
|
(cherry picked from commit 3be250da90dd3d361df713056b881e017684e2b3)
|
|
for exceptions other than those thrown by base-class LLEventDispatcher.
Explain in LLDispatchListener Doxygen comments that for a request lacking a
"reply" key, any exception is allowed to propagate because it's likely to
reach the post() call that triggered the exception in the first place.
For batch LLDispatchListener operations, catch not only LLEventDispatcher::
DispatchError exceptions but any std::exception, so we can collect them to
report to the invoker. "Gotta catch 'em all!"
Make LLLeap catch any std::exception thrown by processing a request from the
plugin child process, log it and send a reply to the plugin. No plugin should
be allowed to crash the viewer.
(cherry picked from commit 94e10fd039b79f71ed8d7e10807b6e4eebd1928c)
|
