summaryrefslogtreecommitdiff
path: root/indra/llcommon/tests/lleventdispatcher_test.cpp
AgeCommit message (Collapse)Author
2023-05-04Merge remote-tracking branch 'origin/zap-LLSDArray' into DRTVWR-577-maint-SAndrey Lihatskiy
2023-05-03SL-19647: Eliminate LLSDArray entirely.Nat Goodspeed
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().
2022-11-03DRTVWR-575: A few more tweaks addressing size_t wider than 32 bits.Nat Goodspeed
2020-04-03DRTVWR-476: Cherry-pick debug aids from commit 77b0c53 (fiber-mutex)Nat Goodspeed
2020-03-25[DRTVWR-476] - fix compiler errors 32 bit windows buildAnchor
2019-08-10DRTVWR-493: Introduce test catch_what(), catch_llerrs() functions.Nat Goodspeed
Use them in place of awkward try/catch test boilerplate.
2015-11-10remove execute permission from many files that should not have itOz Linden
2013-10-21another attempted buildfixRichard Linden
2013-03-29Update Mac and Windows breakpad builds to latestGraham Madarasz
2011-02-09Add test to call map-style functions with full map/array params.Nat Goodspeed
Test also passes overlong arrays and maps with extraneous keys; in all cases we expect the same set of values to be passed to the registered functions.
2011-02-07For test purposes, capture at registration each function's Vars*.Nat Goodspeed
We'd introduced FunctionsTriple to associate a pair of registered function names with the Vars* on which those functions should operate. But with more different tests coming up, it became clear that restating the Vars* every time a given function name appeared in any such context was redundant. Instead, extended addf() to accept and store the relevant Vars* for each registered function, be it the global Vars for the free functions and static methods or the stack Vars for the non-static methods. Added varsfor() function to retrieve and validate the Vars* for a given function name. Eliminated array_funcs() function, restating aggregates of names to test as LLSD collections. Where before these were coerced into a separate LLSD map with ["a"] and ["b"] keys, that map can now be part of the original structure.
2011-02-06Untested support for passing array to map-registered function.Nat Goodspeed
An array-registered function has no param names, so you can only pass an array: a map would be meaningless. Initial implementation of map-registered functions assumed that since you CAN pass a map, you MUST pass a map. But in fact it's meaningful to pass an array as well -- for whatever reason -- and easy to implement, so there you are. Tests to follow.
2011-02-06Add test verifying passing LLSD() to const char* parameter.Nat Goodspeed
LLSDParam<const char*> is coded to pass NULL for an isUndefined() LLSD value, so event-based caller can choose whether to pass NULL, "" or whatever string value to such a parameter. Ensure this behavior.
2011-02-05Introduce zipmap() function and use it in place of frequent loops.Nat Goodspeed
One operation we often use is to take an LLSD array of param names, a corresponding LLSD array of values, and create from them a name=value LLSD map. Instead of doing that "by hand" every time, use a function.
2011-02-05Make array-funcs success test exercise args-array-too-long case too.Nat Goodspeed
Streamline a bit more redundancy from the code in that test.
2011-02-05Consolidate paramsa, paramsb, et al., into ["a"], ["b"] arrays.Nat Goodspeed
Following the C++ convention of having two distinct somethigna, somethingb names, initially we introduced paramsa, paramsb LLSD arrays, following that convention all the way down the line. This led to two distinct loops every time we wanted to walk both arrays, since we didn't want to assume that they were both the same size. But leveraging the fact that distinct LLSD arrays stored in the same LLSD container can in fact be of different lengths, refactored all the pairs of vars into top-level LLSD maps keyed by ["a"] and ["b"]. That lets us perform nested loops rather than duplicating the logic, making test code much less messy.
2011-02-05Fix Vars::cp dangling-pointer problem.Nat Goodspeed
Naively storing a const char* param in a const char* data member ignores the fact that once the caller's done, the string data referenced by that pointer will probably be freed. Store the referenced string in a std::string instead.
2011-02-05Add successful calls to array-style functions.Nat Goodspeed
2011-02-04Change FunctionsTriple refs to pointers to facilitate passing.Nat Goodspeed
A certain popular-but-dumb compiler seems to think that initializing a std::vector from a pair of iterators requires assignment. A struct containing a reference cannot be assigned. Pointers get us past this issue.
2011-02-04Move FunctionsTriple data to function returning vector<same>.Nat Goodspeed
We want to break out a couple different test methods that both need the same data. While we could define a std::vector<FunctionsTriple> in the lleventdispatcher_data class and initialize it using a classic {} initializer as in array_funcs(), using a separate function puts it closer to the tests consuming that data, and helps reduce clutter in the central data class. Either way, it's cool that BOOST_FOREACH() handles the gory details of iterating over a std::vector vs. a classic-C array.
2011-02-03BOOST_FOREACH(LLSD) helpers more readable with 'using namespace'.Nat Goodspeed
2011-02-03Introduce BOOST_FOREACH() helpers for LLSD in llsdutil.h.Nat Goodspeed
You can't directly write: BOOST_FOREACH(LLSD item, someLLSDarray) { ... } because LLSD has two distinct iteration mechanisms, one for arrays and one for maps, neither using the standard [const_]iterator typedefs or begin()/end() methods. But with these helpers, you can write: BOOST_FOREACH(LLSD item, llsd::inArray(someLLSDarray)) { ... } or BOOST_FOREACH(const llsd::MapEntry& pair, llsd::inMap(someLLSDmap)) { ... } These are in namespace llsd instead of being (e.g.) llsd_inMap because with a namespace at least your .cpp file can have a local 'using': using namespace llsd; BOOST_FOREACH(LLSD item, inArray(someLLSDarray)) { ... } It's namespace llsd rather than LLSD because LLSD can't be both a namespace and a class name.
2011-02-03Add test to call array-style functions with too-short array.Nat Goodspeed
Also, finally got sick of hand-writing the official iterator-loop idiom and dragged in BOOST_FOREACH(). Because LLSD has two completely different iteration styles, added inArray and inMap helper classes to be able to write: BOOST_FOREACH(LLSD item, inArray(someArray)) { ... }
2011-02-02Add test to call no-args functions using (map | array)-style callsNat Goodspeed
2011-02-02Add test to exercise map/array args mismatch validation.Nat Goodspeed
2011-02-02First few LLEventDispatcher call cases: try_call(), call CallablesNat Goodspeed
2011-02-01Replace ad-hoc test functions/methods with systematic enumeration.Nat Goodspeed
Previous tests involved a small handful of functions with only a couple different parameter types. Now we exhaustively invoke every registration case, plus every metadata query case. Call cases still pending.
2011-01-28Extend LLEventAPI to directly call other functions & methods.Nat Goodspeed
Until now, LLEventAPI has only been able to register functions specifically accepting(const LLSD&). Typically you add a wrapper method to your LLEventAPI subclass, register that, have it extract desired params from the incoming LLSD and then call the actual function of interest. With help from Alain, added new LLEventAPI::add() methods capable of registering functions/methods with arbitrary parameter signatures. The code uses boost::fusion magic to implicitly match incoming LLSD arguments to the function's formal parameter list, bypassing the need for an explicit helper method. New add() methods caused an ambiguity with a previous convenience overload. Removed that overload and fixed the one existing usage. Replaced LLEventDispatcher::get() with try_call() -- it's no longer easy to return a Callable for caller to call directly. But the one known use of that feature simply used it to avoid fatal LL_ERRS on unknown function-name string, hence the try_call() approach actually addresses that case more directly. Added indra/common/lleventdispatcher_test.cpp to exercise new functionality.