<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/56492>56492</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            Various issues with gtest sharding
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            new issue
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
            yuanfang-chen
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          rorth
      </td>
    </tr>
</table>

<pre>
    Since the gtest-based switched to use sharding with D122251, I've had a considerable number of issues:

- The test names give no indication whatsoever which individual tests have `PASS`ed, `FAIL`ed or whatever, so one cannot easily check `ninja check-all` output for that.  Same problem applies to the buildbots, of course.
- The new test names like `SanitizerCommon-Unit :: ./Sanitizer-x86_64-Test/0/46` are pretty useless because they are volatile: even the addition of removal of a single new test changes the numbering, thus one cannot meaningfully compare different test runs.
- The switch consistently broke the Solaris/amd64 buildbot: while the sanitizer tests worked fine when run sequentially, the claimed optimization of sharding caused some tests to hang indefinitely.  There seems to be kernel lock contention in `procfs` at play here, but turning the buildbot from green to red for months this way isn't exactly pleasant.
- There's at least one bug in the `.json` generation that also breaks the testsuite runs: Issue 56491.

I wonder what the best way forward is here:

- I think the test name issues can be fixed by properly parsing and reporting the output of the individual shard runs, going back to what we had before sharding was introduced.  After all, that's supposed to be an optimization only, thus shouldn't change the test output itself.
- I wonder if it should become possible to choose whether sharding should be used or not.  In cases where it provides no performance gain or even breaks the testsuite, this would provide a way forward.


</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJxtVU1v6zYQ_DX2hbBhyx9JDj6kLwhgoIcCfu21WIkrizFFqiRlx-_Xd5aSHaco4A9JFHdnZmeXpdfX3cG4ilVqWB0TxzQrKbJW8WJS1eAiedVHVrGhoI07Kjxv1NuyKIrNclL8UPtJ8XRm1ZBWpCrvotEcqLSsXN-WHJSvlYmx5zhZvU4Wb5PF-DtTP5FTUipHLUd1NIjjvDJOm4qS8U5dGkrR8xlhLo2pmrx2Nronm3dG5MWmyXbxx-vhgD_WggkX76_73_O98iGHkSCyFr3yjlVFzvmkmKKxVwWm1Um2OeM-aLidkbV4onyfuj6pGnES4syVOgCu6oIHyVZR11kD9NBJNCx7Y3XpU5RcoF75PkSeP1J2fHmkbc0pMziQM8n84vDDt613sz9xq0Sz1auaT4r3-_rs83n793Y9-4kYeL7Ad70VpBQEFqd0lZJZjlGVXJGUD9Cuef3sLaS1LFEhicugSWuT9QbgwK0_Q15ckoqouH1AXDXkjkK2uZUXLwjT1PTxUdeWgdYd696Kur7tJLc2dc2BXRqChd7Fb8IMnhtMFBPew94y-NPgzgOQBwNd36nV2_VdaWECc9jhrXhTafTHxYcTTFAbYLs04IusKvI_PcIbVPg6oAdwS6YVu3TJtOYX3fS4Gz8LicbwLY-xUXLRQ0zJSGAS2yvsASogG5nb_ErJ6sTBsVXWw2RgJ9QkunFSdxipqmOuX1KdpauS_QKrhO1SH0TIb95SdfCtOgaW8nlUTGd3wjSpkdoY0EYYEx16Ex7_pEqk7CzcTi49ai6JnqJklsWUS1j2QilnBKr5R_RO0B3ZobEzcOkDRRatVAam0-CHrEkPEXJhpSp7aXu12a5flvPHzt-jKpBs6MuBmfhBMIPHBXoD-6DCf0fGXui50z1h7qFxvoj3RO3afEKR8iot2nEQ5hTEyYqchlqdD-km6djcqLPcPUyXXPaBCSpx9LKhJNQPgmfYl2HmlQzIj-ORIsKk4HVfsYYbXusEpjJLstEoZcFj33U-DuMVkAH8u-_czZhoq9j43uqhlkMDftEf8ZuEfq_nXyqNAhvM3jQGkFkg3kXeaGQ-I3XVeKCQxkDE8MXivkNlz8NcaGqQ2TuIHCH1JXscsaExFMMTDG6IDTFakvPkSLAQ9uUZ838uGeiJVXOqMQ5mzoMNvrlmqncr_bJ6oWkyyfLuL0wDD3nG4udzKZ9gdxrTPthdk1KXj57iHZ8j3urLOYTAjbXn298M-T-4knk6HlbFuxi3mDa7gitNT6tqSdXmRa9fVrTlTflEz3W5XmnWU0sl27ibbH6bFIXMyhwC15PN29TsikVRLJ6WxXKx2W6e53pL5bpavVTP2wXmBk_WC27J2LngmPtwnIZdhoQ-jFi0mIXxa5FQvaNjHtNde3I1PDHDmeXGlNSnxoddgM-bacayy1z-Bd_PwgE">