fix: correct inverted preserve_order docstring in resolve_matching_names functions

[sellai-youcef]

Description

The preserve_order parameter descriptions were inverted in the docstrings
of resolve_matching_names and resolve_matching_names_values in
source/isaaclab/isaaclab/utils/string.py.

The code logic and examples were already correct — only the prose descriptions
were swapped.

Fixes #5146

Type of change

• Documentation update

Checklist

• I have read and understood the contribution guidelines
• I have made corresponding changes to the documentation
• My changes generate no new warnings

[greptile-apps]

Greptile Summary

This PR corrects the inverted preserve_order docstring descriptions in resolve_matching_names and resolve_matching_names_values in string.py. The fix for resolve_matching_names is logically correct but has two issues: a missing indentation on one line and the companion function resolve_matching_names_values was not updated, leaving its docstring still inverted.

• The If the :attr:\preserve_order` is Trueline inresolve_matching_names` (line 186) is missing its 4-space indent, which will break RST/Sphinx rendering.
• resolve_matching_names_values (lines 283–288) still has the original inversion — True is described as string order and False as query order, contradicting both the code logic and the inline example.

Confidence Score: 3/5

Not safe to merge — the primary fix is incomplete and introduces a formatting defect.

Two P1 issues remain: a missing indentation that will break Sphinx doc rendering, and the sibling function resolve_matching_names_values still carries the inverted docstring that this PR set out to fix.

source/isaaclab/isaaclab/utils/string.py — both the resolve_matching_names indentation fix and the resolve_matching_names_values docstring correction need attention.

Important Files Changed

Filename	Overview
source/isaaclab/isaaclab/utils/string.py	Docstring fix for preserve_order in resolve_matching_names is logically correct but has a missing indentation on one line; resolve_matching_names_values docstring was not updated and remains inverted.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["preserve_order=False (default)"] --> B["Loop over list_of_strings\n(target order)"]
    B --> C["Append matches in\ntarget string order"]
    C --> D["Return indices & names\nin target-string order"]

    E["preserve_order=True"] --> F["Loop over list_of_strings\n(target order)"]
    F --> G["Reorder by key_index\n(query/regex order)"]
    G --> H["Return indices & names\nin query-key order"]

Loading

Comments Outside Diff (1)

1. source/isaaclab/isaaclab/utils/string.py, line 283-288 (link)

   resolve_matching_names_values docstring still inverted

   The PR fixes resolve_matching_names but leaves resolve_matching_names_values with the same original inversion. The code at line 341 (if preserve_order:) reorders by key index (query order), matching the confirmed example: preserve_order=True → ([0, 3, 4, 1, 2], ['a', 'd', 'e', 'b', 'c'], ...) (regex key order), yet the docstring still says True = string order and False = query order.

_{Reviews (1): Last reviewed commit: "Merge branch 'isaac-sim:main' into fix/d..." | Re-trigger Greptile}

[greptile-apps]

Missing indentation on preserve_order=True line

The first line of the preserve_order is True paragraph lost its 4-space indentation during the edit, breaking the docstring's visual alignment and likely causing RST/Sphinx rendering issues (the line will not be treated as a continuation of the same paragraph).

Suggested change

	If the :attr:`preserve_order` is True, the ordering of the matched indices and names is the same as the order
	of the provided list of query regular expressions.
	If the :attr:`preserve_order` is True, the ordering of the matched indices and names is the same as the order
	of the provided list of query regular expressions.

[isaaclab-review-bot]

🤖 Isaac Lab Review Bot

Summary

This PR fixes the inverted preserve_order docstring descriptions in resolve_matching_names, where the prose for True and False were swapped relative to the actual code behavior. The fix is correct — I traced through the implementation and confirmed: when preserve_order=True, the reorder block groups results by key_index order (query key order), and when False, the outer loop over list_of_strings naturally yields target-string order. The examples in the docstring were already correct and remain consistent with the updated prose.

However, there are two issues that need addressing before merge.

Verdict

Minor fixes needed

The docstring correction is accurate, but there’s a missing-indent formatting issue on line 186 and — more importantly — the same inverted docstring bug in resolve_matching_names_values (lines 283–288) was not fixed, despite being explicitly called out in issue #5146. Both should be addressed in this PR.

[isaaclab-review-bot]

🔴 Critical: Missing indentation — This line lost its leading 4-space indent, which will break Sphinx/docstring rendering. The rest of the docstring block uses 4-space indentation; this line must match.

Suggested change

	If the :attr:`preserve_order` is True, the ordering of the matched indices and names is the same as the order
	If the :attr:`preserve_order` is True, the ordering of the matched indices and names is the same as the order

[isaaclab-review-bot]

🟡 Warning: Incomplete fix — resolve_matching_names_values still has the same bug

The linked issue #5146 explicitly calls out that resolve_matching_names_values (lines 283–288) has the identical inverted docstring. The code logic in that function is the same (reorder block runs when preserve_order=True, grouping by query key order), but the docstring there still claims True → target string order and False → query key order — which is backwards.

Please apply the same swap to resolve_matching_names_values so the full issue is resolved in one PR.