| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
since it doesn't seem to have any effect, and it would only get in
the way on other Darwin platforms.
|
|
|
|
on Arm systems.
|
|
|
|
|
|
Same thing as commit cf692c40b0b9f8d0d04cd10a02a84e3f697a2e99
which was removed due to shutdown freezes.
Error thread is no longer there so doesn't cause any race sonditions,
was not able to repro any issues so will ask QA to test shutdown
|
|
|
|
|
|
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
|
|
Useful when installed as shared libraries, so other viewer executables
can share these libraries.
|
|
|
|
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)
|
|
|
|
Even though the account was logged in, it would get stuck at getting
region handshake. The problem was because the viewer wasn't getting the
acknowledgement to the successfully sent UseCircuitCode message. I
compared the message data, and it differed (from Linux) on the byte
order of the Code variable (the SessionID & agent ID were right). The
bytes sent to the network weren't reversed (and I was on an Intel
processor).
|
|
|
|
Otherwise we'd get this.
error: declaration of anonymous struct must be a definition
struct Status
^
indra/llcommon/llprocess.h:284:2: warning:
declaration does not declare anything [-Wmissing-declarations]
|
|
|
|
|
|
|
|
|
|
Relies on sysctl, like on Darwin, and on parsing a file, like on Linux,
except the file would be /var/run/dmesg.boot.
|
|
Since C++11, NULL is promoted to nullptr on some BSD platforms. This is
very problematic when used with Boost. At times it would fail during
compile-time. What's worse is if it passes compile-time, but then crash
during run-time, for example when some condition is to be checked for its
truth, when then it would be compared to a nullptr.
|
|
|
|
I had added this to CMAKE_CXX_FLAGS in 00-Common before, and only when
the compiler was Clang. But it turned out that GCC was treating them as
errors too, that the addition would need to be applied to all compilers.
So I prefer to put it here in llcommon with the scope set to PUBLIC
cause the errors would show up again when compiling other LL libraries
if the scope is set to something else.
|
|
in order to get rid of errors complaining that size_t was not declared
in the scope.
|
|
|
|
|
|
|
|
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().
|
|
|
