Instead of checking whether an add() parameter is exactly LLSD or LLSDMap,
check whether it's convertible to LLSD -- which handles those cases and more.
(cherry picked from commit fa168c11f64771dadc5df86d14ca2f07eba3b8ba)
(cherry picked from commit 6b5bfc1cf674fc568d86d7ed623fd7bb3ee2f646)
Previously, LLEventAPI intentionally hid all but one of the many add()
overloads supported by its LLEventDispatcher base class. The reason was that
certain of the add() methods take an optional fourth parameter that's an
LLSD::Map describing the expected parameter structure, while others take a
fourth templated parameter that's an instance getter callable. This led to
ambiguity, especially when passed an LLSDMap instance that's convertible to
LLSD but isn't literally LLSD. At the time, it was simpler to constrain the
add() methods inherited from LLEventDispatcher.
But by adding new std::enable_if constraints to certain LLEventDispatcher
add() methods, we've resolved the ambiguities, so LLEventAPI subclasses can
now use any add() overload (as claimed on the relevant Confluence page).
LLEventDispatcher comments have always loftily claimed that an instance getter
callable may return either a pointer or a reference, doesn't matter. But it
does when trying to pass the getter's result to boost::fusion::push_back(): a
reference must be wrapped with std::ref() while a pointer cannot be.
std::ref(pointer) produces errors. Introduce LLEventDispatcher::invoker::
bindable() overloads to Do The Right Thing whether passed a pointer or a
reference.
(cherry picked from commit 743f487c2e123171c9fc6d5b84d768f1d856d569)
(cherry picked from commit 8618e41b3489e321ecd70eb65ec4d9ca7e2f75c6)
Originally the LLEventAPI mechanism was primarily used for VITA testing. In
that case it was okay for the viewer to crash with LL_ERRS if the test script
passed a bad request.
With puppetry, hopefully new LEAP scripts will be written to engage
LLEventAPIs in all sorts of interesting ways. Change error handling from
LL_ERRS to LL_WARNS. Furthermore, if the incoming request contains a "reply"
key, send back an error response to the requester.
Update lleventdispatcher_test.cpp accordingly.
(cherry picked from commit de0539fcbe815ceec2041ecc9981e3adf59f2806)
(cherry picked from commit 4b60941952e97691f11806062f4bc66dd5ac8dae)
Instead of std::map<std::string, boost::shared_ptr>, use std::unique_ptr as
the mapped_type, using emplace() to store new entries. This more correctly
captures the desired semantics: we have no intention of passing around the
pointers in the map, we just want the map to delete them on destruction.
Use std::function instead of boost::function.
(cherry picked from commit 7ba53ef82db5683756e296225f0c8b838420a26e)
Add to apply_test.cpp a collect() function that incrementally accumulates an
arbitrary number of arguments into a std::vector<std::string>. Construct a
std::array<std::string> to pass it, using VAPPLY().
Clarify in header comments that LL::apply() can't call a variadic function
with arguments of dynamic size: std::vector or LLSD. The compiler can deduce
how many arguments to pass to a function with a fixed argument list; it can
deduce how many arguments to pass to a variadic function with a fixed number
of arguments. But it can't compile a call to a variadic function with an
arguments data structure whose size can vary at runtime.
(cherry picked from commit ceed33396266b123896f7cfb9b90abdf240e1eec)
Make apply(function, std::array) and apply(function, std::vector) available
even when we borrow the C++17 implementation of apply(function, std::tuple).
Add apply(function, LLSD) with interpretations:
* isUndefined() is treated as an empty array, for calling a nullary function
* scalar LLSD is treated as a single-entry array, for calling a unary function
* isArray() converts function parameters using LLSDParam
* isMap() is an error.
Add unit tests for all flavors of LL::apply().
(cherry picked from commit 3006c24251c6259d00df9e0f4f66b8a617e6026d)
Always search for python3[.exe] instead of plain 'python'. macOS Monterey no
longer bundles Python 2 at all.
Explicitly make PYTHON_EXECUTABLE a cached value so if the user edits it in
CMakeCache.txt, it won't be overwritten by indra/cmake/Python.cmake.
Do NOT set DYLD_LIBRARY_PATH for test executables! That has Bad Effects, as
discussed in https://stackoverflow.com/q/73418423/5533635. Instead, create
symlinks from build-mumble/sharedlibs/Resources -> Release/Resources and from
build-mumble/test/Resources -> ../sharedlibs/Release/Resources. For test
executables in sharedlibs/RelWithDebInfo and test/RelWithDebInfo, this
supports our dylibs' baked-in load path @executable_path/../Resources. That
load path assumes running in a standard app bundle (which the viewer in fact
does), but we've been avoiding creating an app bundle for every test program.
These symlinks allow us to continue doing that while avoiding
DYLD_LIBRARY_PATH.
Add indra/llcommon/apply.h. The LL::apply() function and its wrapper macro
VAPPLY were very useful in diagnosing the problem.
Tweak llleap_test.cpp. This source was modified extensively for diagnostic
purposes; these are the small improvements that remain.
(cherry picked from commit 15d37713b9)
(cherry picked from commit a1adcf1905d1fbc5fe07ff5a627295ccfe461ac4)
Observed on bugsplat, no repro. Something destroys LLConversationItem without cleaning list (some sessions reuse the item, but they aren't supposed to remove it). Either item should inform floater to be properly removed or should be stored as an LLPointer.
Newer C++ compilers have different semantics around LLSDArray's special copy
constructor, which was essential to proper LLSD nesting. In short, we can no
longer trust LLSDArray to behave correctly. Now that we have variadic
functions, get rid of LLSDArray and replace every reference with llsd::array().
It seems newer compilers have a different interpretation of exactly when to
engage LLSDArray's copy constructor. In particular, this assignment:
some_LLSD_map[key] = LLSDArray(...)(...)...;
used to convert the LLSDArray object directly to LLSD; now it first calls the
custom copy constructor, which embeds the intended array within an outer array
before assigning it into the containing map.
The newer llsd::array() function avoids that problem because what it returns
is already an LLSD object.
Taking inventory of LLSDArray assignments of that form turned up a number of
workarounds like LLSD(LLSDArray(...)). Replacing those with llsd::array() is
both simpler and more readable.
Tip of the hat to Chorazinallen for surfacing this issue!
(cherry picked from commit bb718155bd)
The viewer currently presents a startling "Grid emergency" warning if an
unrecognized error is returned from login. Let's tone this down a bit
and present the error as it is: an unrecognized login failure rather
than SLearth exploding.
Nat Goodspeed