fix: avoid mutating strings when building results

[scottmries]

This pulls in changes from the fork, to let our tests run.

The changes look good to me, fwiw.

No QA required

[Copilot]

Pull Request Overview

This PR fixes string mutation issues in the axe-core-api results building logic by replacing in-place prepend operations with string interpolation, ensuring immutability of string objects.

• Replaced line.prepend(" " * 4) with string interpolation in the indent method
• Replaced line.prepend("- ") with string interpolation in the fix method

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
packages/axe-core-api/lib/axe/api/results/rule.rb	Updated indent method to use string interpolation instead of mutating strings with prepend
packages/axe-core-api/lib/axe/api/results/checked_node.rb	Updated fix method to use string interpolation instead of mutating strings with prepend

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Garbee]

I assume the fork is this one correct, https://github.com/G-Rath/axe-core-gems ?

1. What bug is this fixing?
2. This should have unit tests to ensure we don't regress in the future. Very subtle thing here, easy to miss when refactoring.

[scottmries]

@Garbee

I assume the fork is this one correct, https://github.com/G-Rath/axe-core-gems ?

That's right. This is the original PR: #461

1. What bug is this fixing?

It removes a warning about future deprecation of string mutation in Ruby 3.4, possibly breaking in a future release.

2. This should have unit tests to ensure we don't regress in the future. Very subtle thing here, easy to miss when refactoring.

Both of these are private methods whose public uses would be unaffected, and string mutation is tested at the language level; if a future release breaks mutable strings, this will avoid that breakage. Thoughts on this?

responded

[Garbee]

Both of these are private methods whose public uses would be unaffected, and string mutation is tested at the language level; if a future release breaks mutable strings, this will avoid that breakage. Thoughts on this?

I see, from the original PR that explains how this came about. Deprecation message in Ruby itself. Ok, all good then. I was concerned since a consumer saw this and made a PR, that there was something they hit. But if it's purely driven by the language deprecation, then yea no unit tests needed on this. We don't have a scenario that was impacted.

LGTM.