| Age | Commit message (Collapse) | Author |
|---|
|
This is redundant (but harmless) on a Posix system, but it fills a missing
puzzle piece on Windows. The point of fsyspath is to be able to interchange
freely between fsyspath and std::string. Existing fsyspath could be
constructed and assigned from std::string, and we could explicitly call its
string() method to get a std::string, but an implicit fsyspath-to-string
conversion that worked on Posix would trip us up on Windows. Fix that.
(cherry picked from commit fbeff6d8052d4b614a0a2c8ebaf35b45379ab578)
|
|
Our std::strings are UTF-8 encoded, so conversion from std::string to
std::filesystem::path must use UTF-8 decoding. The native Windows
std::filesystem::path constructor and assignment operator accepting
std::string use "native narrow encoding," which mangles path strings
containing UTF-8 encoded non-ASCII characters.
fsyspath's std::string constructor and assignment operator explicitly engage
std::filesystem::u8path() to handle encoding. u8path() is deprecated in C++20,
but once we adapt fsyspath's conversion to C++20 conventions, consuming code
need not be modified.
(cherry picked from commit e399b02e3306a249cb161f07cac578d3f2617bab)
|
|
With the About info added, `getProfileStatsContext()` need not redundantly add
`"channel"`, `"version"` or `"region"`.
Slightly improve the efficiency of `LlsdToJson()` and `LlsdFromJson()` by
preallocating the known size of the source array or map. (Unfortunately the C++
`LLSD` class offers us no way to preallocate a map.)
In `LLAppViewer::getViewerInfo()`, avoid immediate successive calls to
`gAgent.getRegion()`.
(cherry picked from commit f4b65638879c10c832b3bb8448f82001106ffd11)
|
|
|
|
With the About info added, `getProfileStatsContext()` need not redundantly add
`"channel"`, `"version"` or `"region"`.
Slightly improve the efficiency of `LlsdToJson()` and `LlsdFromJson()` by
preallocating the known size of the source array or map. (Unfortunately the C++
`LLSD` class offers us no way to preallocate a map.)
In `LLAppViewer::getViewerInfo()`, avoid immediate successive calls to
`gAgent.getRegion()`.
|
|
|
|
* APR_DECLARE_STATIC and APU_DECLARE_STATIC gets already defined in APR.cmake
* Move both _CRT_SECURE_NO_WARNINGS and _WINSOCK_DEPRECATED_NO_WARNINGS definitions to 00-Common.cmake
* Always define WIN32_LEAN_AND_MEAN and include subset of Windows API by default
* Remove llwin32headerslean.h and remove unnecessary WIN32_LEAN_AND_MEAN definition handling in llwin32headers.h
* Clean up includes of Windows API headers
* Get rid of workaround to link against IPHLPAPI.lib in lluuid.cpp - this seems to have been an issue in the past that has been fixed
|
|
Make Develop->Render Tests->Frame Profile dump JSON to a file too (#2412)
|
|
|
|
secondlife/viewer#2553 about sl crash locale init
|
|
secondlife/viewer#2553
|
|
|
|
|
|
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.
|
|
# Conflicts:
# indra/llcommon/llerror.h
|
|
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.
|
|
|
|
|
|
|
