| Age | Commit message (Collapse) | Author |
|---|
|
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/llcommon/llsdserialize.cpp
# indra/llcommon/llsdserialize.h
# indra/llmath/llvolume.cpp
# indra/llrender/llgl.cpp
# indra/llxml/llcontrol.cpp
# indra/newview/llpanelnearbymedia.cpp
# indra/newview/llsceneview.cpp
# indra/newview/llselectmgr.cpp
# indra/newview/llstartup.cpp
# indra/newview/lltextureview.cpp
# indra/newview/llvovolume.cpp
# indra/newview/skins/default/xui/en/menu_viewer.xml
|
|
# 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use f.writelines((bytes, b'\n')) instead.
|
|
|
|
LLEventTimer supported static run_every(), run_at() and run_after() methods to
schedule future work. This can still be done by deriving from LLEventTimer,
but is better accomplished with a WorkSchedule instance. These convenience
methods, which encourage use of LLEventTimer insted of WorkSchedule, weren't
used except by LLEventTimeout. Remove them and the LLEventTimer::Generic
subclass used to implement them.
Similarly, LLEventTimeout supported static post_every(), post_at() and
post_after() methods based on LLEventTimer::run_every(), run_at() and
run_after(). These weren't used either.
LLRunner is a very old mechanism to schedule future work that seems to be
unused. Research suggests that it's indirectly engaged only by
LLDeferredChain, which isn't used. LLIOSleeper is tested but isn't otherwise
used. Add a deprecation warning to llrun.h prior to excision.
Also replace Boost.Bind with lambdas.
|
|
llsdserialize_test used Boost.Foreach, Boost.Function and Boost.Bind.
llleap_test used Boost.Assign. Both used Boost.Phoenix.
Replace Boost.Foreach with range 'for'.
Replace Boost.Function with std::function.
Replace Boost.Assign with initializer lists.
Replace Boost.Bind and Boost.Phoenix with lambdas.
|
|
NamedTempFile used to use APR calls to discover a suitable temp directory,
synthesize a temp filename template, generate the unique file, write its
content and ultimately delete it. This required a reference to gAPRPoolp as
the default value of an optional constructor argument in case some usage
demanded an alternative APR memory pool. It also used Boost.Phoenix
placeholders to magically synthesize a callable. Replace APR calls with
Boost.Filesystem; replace Boost.Phoenix with lambdas. Break out unique path
generation logic as static NamedTempFile::temp_path(). In a nod to GitHub
Actions builds, honor RUNNER_TEMP environment variable if set.
test.cpp's RecordToTempFile need no longer pass an apr_pool_t* to
NamedTempFile.
NamedTempFile's constructor now accepts an optional suffix, making subclass
NamedExtTempFile nearly trivial. It no longer needs to create or remove a
symlink, for which it used to use APR calls.
llprocess_test.cpp's NamedTempDir used to use Python's tempfile.mkdtemp() to
create a temp directory, and apr_dir_remove() to destroy it. Replace both with
NamedTempFile::temp_path() and Boost.Filesystem.
Also add diagnostic output for LLProcess test failure. If llprocess_test
cannot launch a child process, notice the APR_LOG environment variable
recognized by our patched apr_suite to engage logging, and report the contents
of that file.
|
|
This conditional code hasn't been used since June 2008, possibly even earlier.
|
|
|
|
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
|
|
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().
|
|
|
