<html>
<head>
<base href="https://llvm.org/bugs/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - Consider changing lit core to support setup vs. execute distinction"
href="https://llvm.org/bugs/show_bug.cgi?id=30666">30666</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Consider changing lit core to support setup vs. execute distinction
</td>
</tr>
<tr>
<th>Product</th>
<td>Test Suite
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>lit
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>modocache@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>daniel@zuster.org, llvm-bugs@lists.llvm.org
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>(This task was copied from
<a href="https://reviews.llvm.org/diffusion/L/browse/llvm/tags/RELEASE_390/final/utils/lit/TODO">https://reviews.llvm.org/diffusion/L/browse/llvm/tags/RELEASE_390/final/utils/lit/TODO</a>.
It was originally written by Daniel Dunbar.)
Many of the existing test formats are cleanly divided into two phases, once
parses the test format and extracts XFAIL and REQUIRES information, etc., and
the other code actually executes the test.
We could make this distinction part of lit's core infrastructure and that would
enable a couple things:
* The REQUIREs handling could be lifted to the core, which is nice.
* This would provide a clear place to insert subtest support, because the setup
phase could be responsible for providing subtests back to the core. That would
provide part of the infrastructure to parallelize them, for example, and would
probably interact well with other possible features like parameterized tests.
* This affords a clean implementation of --no-execute.
* One possible downside could be for test formats that cannot determine their
subtests without having executed the test. Supporting such formats would either
force the test to actually be executed in the setup stage (which might be ok,
as long as the API was explicitly phrased to support that), or would mean we
are forced into supporting subtests as return values from the execute phase.
Any format can just keep all of its code in execute, presumably, so the only
cost of implementing this is its impact on the API and futures changes.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>