| Age | Commit message (Collapse) | Author |
|---|
|
If the C++ runtime is already handling an exception, don't try to launch more
Lua operations.
|
|
MSVC's `std::basic_ostream<CHAR>` template is not implemented in a general way:
it can only be instantiated for certain specific `CHAR` types. Declaring a
`std::basic_ostringstream<llwchar>` fails on MSVC with C2941.
Fortunately both llstring.cpp functions that build a `LLWString` incrementally
have the same characteristics: (a) they each build it one character at a time,
and (b) the length of the result `LLWString` won't exceed the known length of
the input string. So it works to declare a `std::vector<llwchar>`, `reserve()`
the input length and `push_back()` individual characters. Then we can use
`LLWString`'s range constructor to immediately allocate the right size.
|
|
MSVC's `std::basic_ostream<CHAR>` template is not implemented in a general way:
it can only be instantiated for certain specific `CHAR` types. Declaring a
`std::basic_ostringstream<llwchar>` fails on MSVC with C2941.
The ugly workaround from Stack Overflow is to clone-and-edit Microsoft's
`std::numpunct` template, locally specializing it for the desired `CHAR` type.
|
|
Many of the string conversion functions in llstring.cpp would build their
result strings using successive concatenation operations, piece by piece. This
can be expensive in allocations. Instead, use a std::basic_ostringstream of
char type appropriate to the return string type to aggregate piecewise string
building.
|
|
`wchar_to_utf8chars()` used to require a `char*` output buffer with no length,
assuming that its caller knew enough to provide a buffer of sufficient length.
In fact a `char[8]` buffer suffices, but nothing in the header indicated that.
Eliminate the output parameter and return `std::string`. Fix the few existing
callers.
Also set an `ll_convert_alias` so that `ll_convert_to<std::string>(llwchar)`
directly calls `wchar_to_utf8chars()`. Replace instances of the workaround
`wstring_to_utf8str(LLWString(1, llwchar))`.
|
|
|
|
Consensus seems to be that (a) string_view is, in effect, already a reference,
(b) it's small enough to make pass-by-value reasonable and (c) the optimizer
can reason about values way better than it can about references.
|
|
|
|
|
|
|
|
Make central Lua engine functionality conditional on that flag.
|
|
Add tests to verify that llless() correctly handles signed <=> unsigned
comparison, which native "<" does not.
|
|
|
|
|
|
|
|
Also add develop branch's comments about llcoro::LockType being deprecated.
|
|
|
|
|
|
(#2507)
|
|
|
|
|
|
|
|
Changes on new main and changes on Lua project branch combined into a header
circularity. Resolved by hoisting coroutine-aware synchronization primitives
out to a new llcoromutex.h file in the `llcoro` namespace, rather than being
literally members of the `LLCoros` class. But retained `using` declarations in
`LLCoros` for backwards compatibility.
|
|
When asked to retrieve a slice starting at an `index > 0`, `getSliceStart()` was
returning an LLSD array whose first `index` entries were `isUndefined()`,
followed by the desired data. Fix to omit those undefined entries.
|
|
That includes scripts run by LLLUAmanager::runScriptFile(), runScriptLine()
et al.
|
|
We may well want to leverage that API for additional queries that could
potentially return large datasets.
|
|
|
|
That is, our replacement `pairs()` forwards the call to built-in `pairs()`
when the passed object has no `__iter()` metamethod. Similarly, our
replacement `ipairs()` forwards to built-in `ipairs()` when the passed object
has no `__index()` metamethod.
This allows for the possibility that the built-in `pairs()` and `ipairs()`
functions engage more efficient implementations than the obvious ones.
|
|
Specifically, make pairs(obj) honor obj's __iter() metamethod if any.
Make ipairs(obj) honor obj's __index() metamethod, if any. Given the semantics
of the __index() metamethod, though, this only works for a proxy table if the
proxy has no array entries (int keys) of its own.
|
|
The point of LLIntTracker is to generate its keys implicitly, so that its int
getKey() can be treated more or less like an instance pointer, with the added
bonus that the key can be passed around via LLSD.
LLIntTracker generates random int keys to try to make it a little harder for
one script to mess with an LLIntTracker instance belonging to another.
|
|
One could argue that LLInstanceTracker is a container of sorts, and erase() is
more conventional. This affects no other code, as destruct() is not currently
referenced.
|
|
Replace the global next(), pairs() and ipairs() functions with a C++ function
that drills down through layers of setdtor() proxy objects and then forwards
the updated arguments to the original global function.
Add a Luau __iter() metamethod to setdtor() proxy objects that, like other
proxy metamethods, drills down to the underlying _target object. __iter()
recognizes the case of a _target table which itself has a __iter() metamethod.
Also add __idiv() metamethod to support integer division.
Add tests for proxy // division, next(proxy), next(proxy, key), pairs(proxy),
ipairs(proxy) and 'for k, v in proxy'. Also test the case where the table
wrapped in the proxy has an __iter() metamethod of its own.
|
|
|
|
|
|
|
|
Trim redundant output from test_setdtor.lua.
|
|
secondlife/viewer#2445
|
|
`setdtor('description', object, function)` returns a proxy userdata object
referencing object and function. When the proxy is garbage-collected, or at
the end of the script, its destructor calls `function(object)`.
The original object may be retrieved as `proxy._target`, e.g. to pass it to
the `table` library. The proxy also has a metatable with metamethods
supporting arithmetic operations, string concatenation, length and table
indexing. For other operations, retrieve `proxy._target`. (But don't assign to
`proxy._target`. It will appear to work, in that subsequent references to
`proxy._target` will retrieve the replacement object -- however, the
destructor will still call `function(original object)`.)
Fix bugs in `lua_setfieldv()`, `lua_rawgetfield()` and `lua_rawsetfield()`.
Add C++ functions `lua_destroyuserdata()` to explicitly destroy a
`lua_emplace<T>()` userdata object, plus `lua_destroybounduserdata()`. The
latter can bind such a userdata object as an upvalue to pass to `LL.atexit()`.
Make `LL.help()` and `LL.leaphelp()` help text include the `LL.` prefix.
|
|
|
|
|
|
and Beq (#2423)
|
|
|
|
|
|
|
|
|
|
Otherwise, an exception raised in the block containing a LuaStackDelta
instance -- that might be caught -- would result in an LL_ERRS() crash. We
can't expect a block exited via exception to keep its contract wrt the Lua
data stack.
|
|
Use a static unordered_map to allow a function receiving (lua_State* L) to
look up the LuaState instance managing that lua_State. We've thought about
this from time to time already. LuaState's constructor creates the map entry;
its destructor removes it; the new static getParent(lua_State* L) method
performs the lookup.
Migrate lluau::set_interrupts_counter() and check_interrupts_counter() into
LuaState member functions. Add a new mInterrupts counter for them.
Importantly, LuaState::check_interrupts_counter(), which is indirectly called
by a lua_callbacks().interrupt function, no longer performs any Lua stack
operations. Empirically, it seems the Lua engine is capable of interrupting
itself at a moment when re-entry confuses it.
Change previous lluau::set_interrupts_counter(L, 0) calls to
LuaState::getParent(L).set_interrupts_counter(0).
Also add LuaStackDelta class, and a lua_checkdelta() helper macro, to verify
that the Lua data stack depth on exit from a block differs from the depth on
entry by exactly the expected amount. Sprinkle lua_checkdelta() macros in
likely places.
|
|
In fact we set mOldValue from mVar, and restore mVar from mOldValue, so the
VAR type makes the most sense. The previous way, you'd get actual errors if
you tried to use TempSet(pointervar, nullptr): that declared mOldValue to be
nullptr_t, which you can't initialize from mVar.
|
|
|
|
|
