XML: keep HTML void element support from changing how malformed XML recovers

[timtebeek]

What's wrong

• rewrite-xml: support HTML void elements in JSP/HTML parsing #7906 added HTML void element support by left-factoring the element rule, so strict XML and HTML-like sources now share one shape:

element
    :   OPEN name=Name attribute*
        (   '/>'
        |   CLOSE
            (   {isVoidElement($name.text)}? voidClose
            |   content* OPEN '/' Name CLOSE
            )
        )
    ;

That PR argued this was safe for XML because the predicate is gated on htmlMode. The predicate is — but the rule shape isn't, and the shape is what determines the resynchronization sets ANTLR's DefaultErrorStrategy uses. Recovery changed for every source the XML parser touches, including strict XML, where the void alternative is never taken.

The input that exposes it: XMLLexer has STRING : '"' ~[<"]* '"', so an attribute value may contain neither " nor <. A value carrying an unescaped quote — routine in embedded expressions such as Azure API Management policies, whose bodies span many lines — ends its STRING at the first embedded quote, and the remainder re-lexes as further attributes.

Under the new shape those recover into an attribute with a synthesized =. Once built, the printer cannot tell it from a real one and writes it back into the source:

     <set-variable name="allowList" value="@{
         string list = "";
-        list += "AAA,";
+        list += "AAA=,";

One level of nesting deeper, the same input instead abandons the rule with a null EQUALS, and visitAttribute throws:

java.lang.NullPointerException: Cannot invoke "org.antlr.v4.runtime.tree.TerminalNode.getSymbol()" because "node" is null
  org.openrewrite.xml.internal.XmlParserVisitor.convert(XmlParserVisitor.java:530)
  org.openrewrite.xml.internal.XmlParserVisitor.lambda$visitAttribute$25(XmlParserVisitor.java:395)

Two symptoms, one cause; nesting alone decides which you get. Neither reproduces on any released version — I checked 8.20.0, 8.40.0 and 8.56.1, and confirmed by bisect and by reverting only rewrite-xml/ onto current main.

The fix

• Give strict XML back its original rule, gated by isHtmlMode(), so HTML keeps the left-factored shape and XML keeps the recovery behaviour it had before rewrite-xml: support HTML void elements in JSP/HTML parsing #7906. This is what makes "HTML support does not affect XML parsing" true of recovery and not only of matching.

• Reject attributes and elements that recovery left incomplete or invented. visitAttribute now rejects a context with a missing Name/STRING or a synthesized EQUALS, and visitElement rejects a nameless element, so the document falls back to a ParseError that preserves the original text — the contract XML: harden parser against malformed input crashes #7555 established for other malformed input. A synthesized token is detectable (getTokenIndex() < 0); a synthesized = in a built Xml.Attribute is not, which is why this has to happen at the parse tree.

These files genuinely are not well-formed XML — xmllint rejects them — so a ParseError is the right outcome. What isn't right is a crash, or a reprint that differs from the input.

I deliberately did not blanket-null-guard convert(TerminalNode, ...). On its own that converts the crash into a silently wrong LST and hides the grammar problem, which is strictly worse; the print-idempotency check only catches corruption that happens to be visible in the reprint.

Tests

Three tests in XmlParserTest, each verified to fail without the main-source change and pass with it:

• attributeValueWithUnescapedQuoteIsNotGivenAnExtraEquals — round-trips again instead of gaining an =

• policyExpressionAttributeValueIsNeverRewritten — a policy-style document; ParseError, text byte for byte, and asserts no AAA= in the reported diff

• nestedAttributeValueWithUnescapedQuoteAndAngleBracketDoesNotThrow — ParseError rather than an NPE

• :rewrite-xml:test and :rewrite-maven:test are green, including the void element and JSP tests from rewrite-xml: support HTML void elements in JSP/HTML parsing #7906.

Notes

• Draft: I'd like a second opinion on gating the element rule on isHtmlMode() versus keeping one shape and constraining recovery some other way. Duplicating the alternatives grows the ATN, but it is the only version I found that leaves XML recovery provably untouched.
• The C# grammar sources under rewrite-csharp/ are left alone, matching rewrite-xml: support HTML void elements in JSP/HTML parsing #7906, which also did not regenerate them; XMLParserBase has no C# counterpart yet.

[timtebeek]

Closing as a duplicate of #8562, which covers this and does it better.

I ran both against a shared corpus. #8562 alone already resolves the two symptoms this PR was opened for — the invented = and the TerminalNode.getSymbol() NPE both land on a clean Malformed attribute message. Gating the element rule on isHtmlMode() on top of it makes two cases worse, because #8562's guards are tuned to the current left-factored recovery shape and reverting XML to the older shape routes those inputs down paths the guards don't cover:

Input	#8562 alone	#8562 + this PR
nested unescaped quote + <	Malformed attribute	not print idempotent
multi-line policy expression	Malformed attribute	NullPointerException

Everything else in the corpus was identical, including void element handling for .html vs .xml, so the gate isn't buying anything there either.

The #7906 attribution is already captured in #8562's description via the 8.84.4 bisect, so nothing here is additive.