Repository navigation
Text given for a key to ll or llcompat is passed as LSL passed it, not through uuid() - #437
Conversation
|
Important Review skippedReview was skipped as selected files did not have any reviewable changes. ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Summary
Merge Risk: ⚪ Minimal · up to The change is mergeable after normal checks; the supplied evidence establishes no actionable issue. Pre-merge checks |
  |
| Check name | Status | Explanation | Resolution |
|---|---|---|---|
| Docstring Coverage |  |
Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 11 functions across 2 files. (1 skipped: 1… | Write docstrings for the functions missing them to satisfy the coverage threshold. |
✅ Passed checks (4 passed)
-
-
Check name Status Explanation Title check The title clearly describes the main change: preserving text passed to key parameters of ll and llcompat instead of converting it with uuid(). Description check The description provides clear context, problem details, implementation scope, behavior for UUID literals and script-defined functions, and test results. It does not use the template headings, provide… Linked Issues check Check skipped because no linked issues were found for this pull request. Out of Scope Changes check Check skipped because no linked issues were found for this pull request.
-
Full details: Docstring Coverage
-
-
Explanation
Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 11 functions across 2 files. (1 skipped: 1 unsupported.)
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
A rabbit checks each key with care,
Text stays text as it goes there.
UUIDs keep their proper track,
Tests confirm the values back.
I thump my paws and nibble hay,
Then hop along my merry way.
Comment @coderabbitai help to get the list of available commands.
…nction took it
SLua's ll and llcompat take a key argument as a uuid or as any string,
and the function itself decides whether the text is a key, as LSL's did.
The converter wrapped such text in uuid(), which the definitions' uuid
parameters asked for. But uuid() stops the script on text that is no
UUID: with no "selected" in the JSON, llKey2Name(llJsonGetValue(msg,
["selected"])) answered "" in LSL, and its conversion stopped the
script. The text is now given as it is, `:: any` telling the type
checker, with a note once a script saying why. A UUID written out is
still a uuid, and the script's own function's key parameter still takes
uuid(), since its body may compare it with one.
allsltoslua 84 (strict too, and close to LSL), and 23, whose
llGetOwnerKey("abc") is no longer uuid("abc").
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
3885a7b to
7e9a2da
Compare
A follow-up to #434 from Tapple's QA. Where an
llorllcompatfunction takes a key, the converter now passes LSL text as it is, as LSL's function took it. It no longer wraps the text inuuid(), which stops the script on text that isn't a UUID.The problem
uuidor as any string (llsl.cpp, slua 0.732.16). The function then decides whether the text is a key, as LSL's did.uuid, so the converter wrapped text inuuid(). Butuuid()raises "Unable to convert to UUID" on text that isn't a UUID.llKey2Name(llJsonGetValue(msg, ["selected"])). When the JSON has no"selected",llJsonGetValuereturnsJSON_INVALID. LSL'sllKey2Nameanswered""for that; the converted line stopped the script.The change
llorllcompatkey parameter is written as it is, with:: anyso the type checker accepts it:ll.Key2Name(ll.JsonGetValue(msg, {"selected"}) :: any). Anything other than a single term is bracketed first.uuid("…").uuid(), since its body may compare it with auuid.uuidonly is still the right nudge for code written in SLua.Testing
allsltoslua77/77 under both Luau solvers.llGetOwnerKey("abc")is no longeruuid("abc").alluaufragment. It fails intermittently, and fails 3 runs in 6 without this change as well. That is the fragment answer atscope3.lsl29:1.🤖 Generated with Claude Code