SONARXML-180 : Fix FP in IndentationCheck (S1120) for string line continuation

[rombirli]

Important notes

As noted in Gabriel's review, this PR will trim a few True Positives (TPs) in specific scenarios like the one below:

<string name="lipsum">Lorem ipsum dolor, sit ame
conesctetur</string> 

Current Context & Rationale

Currently, an issue is reported on the closing tag (</string>) for the wrong reason.

• The "Actual" Reason: SonarXML raises an issue on the closing tag simply because it miscalculates the indentation based on the number of characters preceding the tag on that same line.
• The "Expected" Reason: If we were to report this properly (as Gabriel suggested), the issue should actually be on the second line of the content, because the line continuation should be indented one level further than the opening tag.

Why I chose not to implement the "Proper Check"

While Gabriel proposed checking string content indentation properly, I have decided to keep string content ignored in IndentationCheck. I believe this remains the best option for the following reasons:

1. Avoiding False Positives (FPs): While conventions exist for simple multiline strings (Line Continuations and Multiline Strings), XML is frequently used to wrap raw data or code snippets (like the example below). In these cases, standard indentation rules are often not relevant.
2. Embedded Content Complexity: In scenarios like this, a "proper" indentation check would produce significant noise:

<bean id="bean1" class="org.abc.ClassA">
  <constructor-arg>
    <value>inline:
package org.abc;

class ClassA {
  int function1() {
      return 0;
  }
}
    </value>
  </constructor-arg>
</bean>

By maintaining the exclusion of string content from the check, and keeping the trivial check, we avoid reporting "accidental" issues on closing tags while preventing a high volume of False Positives in files containing embedded scripts or formatted text.

[hashicorp-vault-sonar-prod]

SONARXML-180

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
94.7% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[github-actions]

This PR is stale because it has been open 7 days with no activity. If there is no activity in the next 7 days it will be closed automatically

[GabrielFleischer]

I think your method is a bit too broad and trim too many TPs.

I provided you with a moretest cases.

[rombirli]

I spent way too much time on it and it looks fixing it would be more complicated than initially expected.

[GabrielFleischer]

As discussed, I join you on the fact that the lost FPs provide more value than the lost TPs.

So, LGTM

I still thing the comment explaining the exception would be better by using whitespaces rather than -, but this is nitpicky.

[rombirli]

As discussed, I join you on the fact that the lost FPs provide more value than the lost TPs.

So, LGTM

I still thing the comment explaining the exception would be better by using whitespaces rather than -, but this is nitpicky.

good catch, I applied the suggestion

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
94.7% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[dorian-burihabwa-sonarsource]

Blocking to keep out of release 2.15