Bazel does not accept certain time values on testcases

[travisdowns]

Description of the bug:

bazel test consumes the rest result file written to the location specified by env var XML_OUTPUT_FILE, which is in "junit result format" and might look like so:

<testsuite tests="17" skipped="0" errors="0" failures="0" id="0" name="auto_fmt" time="0.000938">
<testcase assertions="1" name="auto_fmt_0" time="1.1e0">
</testcase>
...
</testsuite>

Note the time="1.1e0" attribute on the first testcase. Bazel correctly parses this as 1.1 seconds. However, if the value is 1e0 (or any other value without any decimal point to the left of the e), the parsing apparently fails and bazel reports 0 test cases for the entire test (even if only 1 testcase has such a value).

Having a no decimal point is generally valid (most langs accept this, I could not find a counter-example at least) and this should be parsed correctly.

These values were written by Boost test's JUNIT writer.

Which category does this issue belong to?

Core

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

create a test that just writes the following to the XML_OUTPUT_DIR location:

<?xml version="1.0" encoding="UTF-8"?>
<testsuite tests="1" skipped="0" errors="0" failures="0" id="0" name="repro" time="0.000938">
<testcase assertions="1" name="repro_tc" time="1e0">
</testcase>
</testsuite>

Which operating system are you running Bazel on?

Linux

What is the output of bazel info release?

release 7.4.0

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

I downloaded bazel.

What's the output of git remote get-url origin; git rev-parse HEAD ?

n/a

If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.

Did not attempt.

Any other information, logs, or outputs that you want to share?

JUNIT XML schema seems to define this field as xs:decimal type which arguably should not support scientific notation at all, but in any case Bazel is correctly parsing the cases with a decimal point, which seems inconsistent.

[rockwotj]

Seems like this is maybe a Java issue?

EDIT: hrm Double.parseDouble seems fine with this:

[rockwotj]

Ah found it:

https://cs.opensource.google/bazel/bazel/+/master:src/main/java/com/google/devtools/build/lib/exec/TestXmlOutputParser.java;drc=7d2509e8a4e27810143b462bd0f2cfc21b48193b;bpv=0;bpt=1;l=32

Seems there is some nasty historical artifact at play:

https://cs.opensource.google/bazel/bazel/+/master:src/main/java/com/google/devtools/build/lib/exec/TestXmlOutputParser.java;l=168-175;drc=7d2509e8a4e27810143b462bd0f2cfc21b48193b

[rockwotj]

A hacky fix: 3da4989

(also note that comment is a bit backwards