Age | Commit message (Collapse) | Author |
|
|
|
macOS clang produces fatal warnings when trying to pass a const char*
parameter to luaL_error() (-Wformat-security). Temporarily suppressing that
requires #pragma clang directives which, in turn, produce fatal warnings in
VS.
Moreover, VS recognizes that luaL_error() never returns, and so diagnoses the
following return statement as unreachable code. But that return statement is
the whole reason for lluau::error()'s existence...
|
|
|
|
We were calling lua_pcall() in such a way as to discard any values returned by
the Lua chunk.
Work around Luau's broken lua_tointegerx(), which unlike vanilla Lua's does
not report whether the value at the specified index is or is not an integer.
|
|
|
|
Add LuaState::expr() that evaluates a Lua snippet and reports back any result
(or error) left on the stack.
Add LLLUAmanager::runScriptFile() and runScriptLine() overloads that accept a
callback with an (int count, LLSD result) signature. The count disambiguates
(error, no result, one result, array of results). Also add overloads that accept
an existing LuaState instance. Also add waitScriptFile() and waitScriptLine()
methods that pause the calling coroutine until the Lua script completes, and
return its results.
Instead of giving LuaState a description to use for all subsequent checkLua()
calls, remove description from its constructor and data members. Move to
expr() and checkLua() parameters: we want a description specific to each
operation, rather than for the LuaState as a whole. This prepares for
persistent LuaState instances.
For now, the existing script_finished_fn semantics remain: the callback will
be called only when the LuaState is destroyed. This may need to change as we
migrate towards longer-lasting LuaState instances.
Make lua_function(name) macro append suffixes to the name for both the
LuaFunction subclass declaration and the instance declaration. This allows
publishing a lua_function() name such as sleep(), which already has a
different C++ declaration.
Move the Lua sleep() entry point to a standalone lua_function(sleep), instead
of a lambda in the body of runScriptFile().
|
|
The intention is to decentralize Luau entry points into our C++ code,
permitting a given entry point to be added to the .cpp file that already deals
with that class or functional area. Continuing to add every such entry point
to llluamanager.cpp doesn't scale well.
Extract LuaListener class from llluamanager.cpp to its own header and .cpp
file.
Extract from llluamanager into lua_function.h (and .cpp) declarations useful
for adding a lua_function Luau entry point, e.g.:
lua_register()
lua_rawlen()
lua_tostdstring()
lua_pushstdstring()
lua_tollsd()
lua_pushllsd()
LuaPopper
lua_function() and LuaFunction class
LuaState
lua_what
lua_stack
DebugExit
|
|
LLDispatchListener::getPumpName() went away when LLEventStream became one of
its base classes. The assumption was that LLEventStream::getName() would
suffice. Re-add getPumpName(), forwarding to getName(), for backwards
compatibility.
|
|
|
|
# Conflicts:
# indra/llcommon/CMakeLists.txt
# indra/newview/llspatialpartition.cpp
# indra/newview/llviewergenericmessage.cpp
# indra/newview/llvoavatar.cpp
|
|
using for DRTVWR-559
|
|
ensure inventory skeleton loading doesn't block the message system from processing packets.
|
|
Also ditch crufty CMake logic related to lleventhost, which we haven't used
for years.
|
|
If not, the resulting error message is so mysterious that it's worth adding an
error check to explain how to avoid it.
|
|
|
|
|
|
We define a specialization of LLSDParam<const char*> to support passing an
LLSD object to a const char* function parameter. Needless to remark, passing
object.asString().c_str() would be Bad: destroying the temporary std::string
returned by asString() would immediately invalidate the pointer returned by
its c_str(). But when you pass LLSDParam<const char*>(object) as the
parameter, that specialization itself stores the std::string so the c_str()
pointer remains valid as long as the LLSDParam object does.
Then there's LLSDParam<LLSD>, used when we don't have the parameter type
available to select the LLSDParam specialization. LLSDParam<LLSD> defines a
templated conversion operator T() that constructs an LLSDParam<T> to provide
the actual parameter value. So far, so good.
The trouble was with the implementation of LLSDParam<LLSD>: it constructed a
_temporary_ LLSDParam<T>, implicitly called its operator T() and immediately
destroyed it. Destroying LLSDParam<const char*> destroyed its stored string,
thus invalidating the c_str() pointer before the target function was entered.
Instead, make LLSDParam<LLSD>::operator T() capture each LLSDParam<T> it
constructs, extending its lifespan to the lifespan of the LLSDParam<LLSD>
instance. For this, derive each LLSDParam specialization from LLSDParamBase, a
trivial base class that simply establishes the virtual destructor. We can then
capture any specialization as a pointer to LLSDParamBase.
Also restore LazyEventAPI tests on Mac.
|
|
They do work fine on clang... unblocking the rest of the team during diagnosis.
|
|
|
|
|
|
# Conflicts:
# autobuild.xml
# indra/llcommon/tests/llleap_test.cpp
# indra/newview/viewer_manifest.py
|
|
clang has gotten smart enough to recognize an inline attempt to store to
address zero. Fool it by storing to an address passed as a parameter, and pass
nullptr from a different source file.
|
|
The header file documents that no llrand function should ever return a value
equal to the passed extent, so the one test in llrand_test.cpp that checked
less than or equal to the high end of the range was anomalous.
But changing that to an exclusive range means that we no longer need separate
exclusive range and inclusive range functions. Replace
ensure_in_range_using(), ensure_in_exc_range() and ensure_in_inc_range() with
a grand unified (simplified) ensure_in_range() function.
|
|
It's frustrating and unactionable to have a failing test report merely that
the random value was greater than the specified high end. Okay, so what was
the value? If it's supposed to be less than the high end, did it happen to be
equal? Or was it garbage? We can't reproduce the failure by rerunning!
The new ensure_in_exc_range(), ensure_in_inc_range() mechanism is somewhat
complex because exactly one test allows equality with the high end of the
expected range, where the rest mandate that the function return less than the
high end. If that's a bug in the test -- if every llrand function is supposed
to return less than the high end -- then we could simplify the test logic.
|
|
Add from_lua() function to run a small Lua script that constructs a specified
Lua object and posts it back to the test program via a temporary LLEventPump.
Call this with a variety of Lua objects, comparing to the expected LLSD.
Add round_trip() function to run another small Lua script that listens for
incoming LLEventPump events and, for each, posts the received Lua data back to
the test program as LLSD. Call this with a variety of LLSD objects, comparing
to the expected LLSD. Also collect these objects into an LLSD array and send
that for a round trip; also collect into an LLSD map and send that.
Sadly, tests currently drive an access violation when trying to convert a
nested Lua table to LLSD.
Add verbose debug logging to lua_tollsd() to identify the context at which we
hit the access violation.
Add comments describing further exceptions to LLSD-to-Lua round trip identity.
Add lua_what() iostream manipulator to stream whatever we can readily
discover about a value at a specified Lua stack index.
Add lua_stack() to report the contents of the Lua stack. Since the stack is
created anew for every call to a C function, this shouldn't usually be
enormous.
Add hexdump.h with iostream manipulators to dump a byte range as hex digits,
or to produce readable text from a mix of printing and nonprinting ASCII
characters.
|
|
|
|
looks like pool regularly gets corrupted, try using separate pool
|
|
|
|
# Conflicts:
# indra/newview/llinventorymodel.cpp
# indra/newview/llvovolume.cpp
|
|
# Conflicts:
# indra/newview/CMakeLists.txt
# indra/newview/VIEWER_VERSION.txt
# indra/newview/llagent.cpp
# indra/newview/llfloaternewfeaturenotification.cpp
# indra/newview/llinventorybridge.cpp
# indra/newview/llinventorymodel.cpp
# indra/newview/lloutfitgallery.cpp
# indra/newview/llpanelmaininventory.cpp
# indra/newview/llpanelmaininventory.h
# indra/newview/llsidepaneltaskinfo.cpp
# indra/newview/llsidepaneltaskinfo.h
# indra/newview/lltexturectrl.cpp
# indra/newview/lltexturectrl.h
# indra/newview/llviewerinventory.cpp
# indra/newview/llviewerobject.cpp
# indra/newview/llviewertexturelist.cpp
# indra/newview/llviewertexturelist.h
# indra/newview/skins/default/xui/en/floater_new_feature_notification.xml
# indra/newview/skins/default/xui/en/menu_inventory.xml
|
|
The first test runs a Lua script that calls post_on(), listen_events() and
await_event() to engage in LLEventPump handshakes with the test program.
Make llluamanager.cpp testable by putting LL_TEST conditionals around lots of
viewer-internals headers and the lua_function definitions that engage them.
Since LuaListener::connect() is called by its constructor, make it a static
method that explicitly accepts the lua_State* (instead of finding it as
mState). Add that parameter to its two existing calls.
Add a debug log message when LuaListener is destroyed. This surfaced the need
to pass a no-op deleter when listen_events() constructs a LuaListener::ptr_t.
When compiled for LL_TEST, make LuaListener::mReplyPump an
LLEventLogProxyFor<LLEventStream> instead of a plain LLEventStream.
For debugging purposes, add a type string "LLEventLogProxy" for
LLEventPumps::make(). A make() call with this type will return an
LLEventLogProxyFor<LLEventStream>.
|
|
On a low-powered GitHub Mac runner, the system doesn't wake up as soon as it
should, and we get spurious "too late" errors. Try a bigger time increment.
(cherry picked from commit 045342ba29aae186e13c711bd4dd84377d4a7e43)
|
|
Use whole seconds rather than tenths of seconds, since apparently the TeamCity
agent machine is having trouble waking up within tenths of seconds.
|
|
Move hexdump() and hexmix() stream formatters to new hexdump.h for potential
use by other tests.
In toPythonUsing() helper function, add a temp file to receive Python script
debug output, and direct debug output to that file. On test failure, dump the
contents of that file to the log.
Give NamedTempFile::peep() an optional target std::ostream; refactor
implementation as peep_via() that accepts a callable to process each text
line. Add operator<<() to stream the contents of a NamedTempFile object to
ostream -- but don't use that with LL_DEBUGS(), as it flattens the file
contents into a single log line. Instead add peep_log(), which streams each
individual text line to LL_DEBUGS().
|
|
|
|
|
|
|
|
|
|
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/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
|
|
|
|
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.
|
|
|
|
|