It used `a = lst[i]` instead of taking the stride index into account (that is, it should have been `a = lst[i+idx]`). Anyway, the exact same value is in b, so use that instead.
Test case by Tapple Gao.
When the tree has a unary minus node (NEG) whose child is a product node (*), and the left operand of the product node starts with a minus sign but is not a NEG node, this produced at least two minus signs in sequence without any spaces.
Normally, OptSigns hides this problem, but when it is disabled, or when the left factor is a pre-decrement (--V) node, the problem is visible.
Fix by creating a function that detects all kinds of leading minus signs, and use it in place of the comparison with NEG.
Fixes#31. Reported by @KrsityKu, who also provided a repro.
- Fix case where CONST < FNCALL or FNCALL < CONST, when the function was marked as SEF but the args were not SEF, could result in the FNCALL being optimized out, thus failing to apply the side effects of the arguments.
- Copy the function's `min` and `max` present in the symbol table, to the node; use the node's `min` and `max` properties in the `<` operator instead of looking up the symbol and using that.
- Extend it to cover all cases where CONST < SEFexpr and SEFexpr < CONST where SEFexpr.min and SEFexpr.max are defined.
The node containing the separator was not being copied; if it was modified by a later optimization step, the modification propagated to all previous nodes that contained it, causing incorrect results.
Many thanks to @KrsityKu for reporting and providing a repro.
Fixes#23.
The unstable flag does not make sense in void functions; add warning.
Also, new upstream version of builtins.txt with new functions that have been added to fndata.txt.
In Python 2, function type names from buiiltins.txt were entered into the tables as Unicode, causing the output module to promote strings to Unicode, and causing trouble further down the line.
Entering them as str fixes the issue.
Thanks a lot to @PeterStindberg for reporting the issue and providing a script that reproduces it.
Fixes#21
The official distribution of Python 2.7 on Windows is built with "narrow strings" (UTF-16 strings with no proper indexing or length). This makes some tests fail. "Fix" this by monkey-patching a few functions and using a wrapping unicode class, as we can't monkey-patch the actual unicode type.
This is very fragile code, but it's the best we could do given the limitations.
There were multiple encoding issues, especially on Windows. Address them by loading the file in binary and converting to Unicode for internal use. This means that the function/event tables are now Unicode.
Originally reported by @Tonaie (see #20).
Previously, llChar formed an UTF-8-1993 string with the given code and converted that, resulting in multiple question marks when the conversion to Unicode forced by Mono caused errors in multiple characters. They have changed the implementation and now it also considers U+FFFF invalid, and only returns one U+FFFD character if the input is invalid, and LSO behaves the same as Mono (no UTF-8-1993 anymore).
We've also detected problems with Windows (who else would it be) for the Unicode "astral" planes (planes beyond the Basic Multilingual Plane), so now there are new tests that include characters > U+FFFF. And since some builds of Python 2 use UTF-16 internally, we also check llSubString and friends with positions after an astral plane character. This is currently failing under Windows, as there are numerous encoding and line ending problems happening on that OS, especially with Python 3.
This enables an option that was being done unconditionally: to swap the `if` and `else` branches if the condition is shorter when negated.
Enabled by default.
Fixes#19. Thanks to SaladDais for the report and test case.
With constant folding inactive, the dead code removal optimization was removing globals and their symbols when they were e.g. integer constants, without substituting them in other globals. This produced a crash when the output module tried to access said symbols.
For example, in this code:
```
integer A = 1;
integer B = A;
default{timer(){llBreakLink(B);}}
```
the line `integer A = 1` was being removed, as well as the `A` global symbol, but the line `integer B = A` was retained with the missing symbol, and the output module crashed when trying to look up the `A` symbol.
Apparently, it wasn't an issue when constant folding was active (which is why it went unnoticed for so long) because the constant folding code sets 'orig' in the symbol table to the original value the variable was being set to, which let the output module know what to output.
The fix is to replace the references to deleted symbols with their values in global definitions. In normal code that was already happening.
As of Second Life Server 2022-09-09.574921, STATUS_DIE_AT_EDGE and STATUS_DIE_AT_NO_ENTRY return their corresponding settings rather than always FALSE.
Regression/coverage tests are clearly lacking in this area, as the change didn't trigger any test breakage, therefore add some unit tests.
llDumpList2String has changed its behaviour with respect to minus zero. Now it converts -0.0 to a string without the minus sign.
While testing this, we noticed several mismatches in the float to string conversions; the existing routine did not properly convert some values because as we discovered later, it is subject to double rounding; one of them is the built-in round-to-nearest-or-even while getting the first 7 significant digits, and the other is just an increment when the digit is a 5 or more, so round to nearest, ties away from zero, and is performed on the digit past the five or six visible digits that LSL shows.
The new code is a tad easier to understand and more robust.
A first variant of the new code is left commented out for history's sake, and will be removed in the next commit.
