Add tests for parsing of inline HTML when rendering markdown as HTML

[d-ronnqvist]

Bug/issue #, if applicable:

Summary

This is a follow up change from #1369

It adds tests for how the DocCHTML/MarkdownRenderer processes inline HTML—skipping any comments while preserving the rest. With these tests in place, I could refactor the implementation with more confidence and extract the inner loop into a private function.

Dependencies

None.

Testing

Nothing in particular for this PR. It only adds tests and makes minor code cleanup to functionality that is only exercised in tests so far. See #1366 for how it eventually does get used.

Checklist

Make sure you check off the following items. If they cannot be completed, provide a reason.

• Added tests
• Ran the ./bin/test script and it succeeded
• Updated documentation if necessary

[d-ronnqvist]

@swift-ci please test

[patshaughnessy]

This looks much better now - thanks for refactoring this! With the new comments and extracted functions it's much easier for me to follow the algorithm 👍

[patshaughnessy]

Did you run into some crashes while running your new tests in Linux CI?

[d-ronnqvist]

No, the Linux CI doesn't encounter any crashes with these changes. Locally, a Swift 6.0.3 container also didn't have any issues with the implementation in either 84dbf48 or e540ba3.

[patshaughnessy]

Since you're using a slice here, I imagine this is quite efficient, even though we are mutating remainder.

[d-ronnqvist]

Yes, because a slice is a portion of a buffer that's owned by another object, mutating the slice can be thought of as updating the start and end indices, which is very cheap.

If you use the Godbolt Compiler Explorer you can see that these two implementations produce rather comparable assembly code:

// Iterating over an array
func iterate(over numbers: [Int], doing work: (Int) -> Void) {
    for number in numbers {
        work(number)
    }
}

// Mutating a slice by repeatedly popping the first element
func iterate(over numbers: [Int], doing work: (Int) -> Void) {
    var remainder = numbers[...]
    while let number = remainder.popFirst() {
        work(number)
    }
}

Further; if the "work" is known to the compiler, like in the comparison below, then the Swift compiler is more likely to be able to optimize away those extra retain and release calls:

// Iterating over an array
func sum(numbers: [Int]) -> Int {
    var total = 0
    for number in numbers {
        total += number
    }
    return total
}

// Mutating a slice by repeatedly popping the first element
func sum(numbers: [Int]) -> Int {
    var total = 0
    var remainder = numbers[...]
    while let number = remainder.popFirst() {
        total += number
    }
    return total
}

[d-ronnqvist]

@swift-ci please test