This is an archive of the discontinued LLVM Phabricator instance.

Escape ]]> in xunit xml output
ClosedPublic

Authored by arichardson on May 15 2018, 9:02 AM.

Details

Summary

This sequence ends the CDATA block so any characters after that are no
longer escaped. This can be fixed by replacing "]]>" with "]]]]><![CDATA[>".

Diff Detail

Event Timeline

arichardson created this revision.May 15 2018, 9:02 AM
cmatthews accepted this revision.May 15 2018, 9:48 AM

Is this an issue you are hitting? I noticed we spend a lot of time in string replace while writing the xunit files when the output is large (for instance if every test in the test suite fails). I was hoping the number of replaces we do could go down.

Besides that LGTM.

This revision is now accepted and ready to land.May 15 2018, 9:48 AM
delcypher added inline comments.May 15 2018, 9:53 AM
utils/lit/tests/xunit-output.py
2

@cmatthews
Wait. I know this isn't part of the patch but what's that || true doing there? That's ignoring the exit code of lit. Do we really want to do that?

There is a test case that intentionally fails to provide failing output. That makes lit return an error exit value. Any way to change what lit exits with?

Is this an issue you are hitting? I noticed we spend a lot of time in string replace while writing the xunit files when the output is large (for instance if every test in the test suite fails). I was hoping the number of replaces we do could go down.

Besides that LGTM.

I currently don't have a test that triggers this behaviour but I believe I originally did hit this when I first implemented this escaping. Will python return a new string if the ]]> is not included in the input? If not I doubt this adds that much overhead compared to the tons of replacements that were needed to replace all XML chars before.

Regarding the || true: I guess that should just be not llvm-lit instead?

There is a test case that intentionally fails to provide failing output. That makes lit return an error exit value. Any way to change what lit exits with?

Not that I know of. But if you're expecting lit to return a non zero exit code should you run not %{lit} ... instead?

The test does not care what the return code of lit is, just that the xml output is correct.

The test does not care what the return code of lit is, just that the xml output is correct.

That seems a little risky to me. The lit command could fail to execute and you could pick up an old copy of %t.xunit.xml from a previously passing run because AFAIK %t.xunit.xml expands to something deterministic.
Because the exit code is completely ignored we would definitely miss this, where-as if the exit code was checked we would be less likely (but not guaranteed) to miss this.
In reality we probably ought to rm -f %t.xunit.xml first before running the test.

Sure, I will update the test today.

This revision was automatically updated to reflect the committed changes.