Lines Matching full:program

4 .. program:: lit
9 :program:`lit` [*options*] [*tests*]
14 :program:`lit` is a portable tool for executing LLVM and Clang style test
16 :program:`lit` is designed to be a lightweight testing tool with as simple a
19 :program:`lit` should be run with one or more *tests* to run specified on the
24 tests have been run :program:`lit` will print summary information on the number
26 :program:`lit` program will execute with a non-zero exit code if any tests
29 By default :program:`lit` will use a succinct progress display and will only
31 options controlling the :program:`lit` progress display and output.
33 :program:`lit` also includes a number of options for controlling how tests are
37 Finally, :program:`lit` also supports additional options for only running a
41 :program:`lit` parses options from the environment variable ``LIT_OPTS`` after
43 supplementing or overriding the command-line options supplied to :program:`lit`
46 :program:`lit` can also read options from response files which are specified as
52 Users interested in the :program:`lit` architecture or designing a
53 :program:`lit` testing implementation should see :ref:`lit-infrastructure`.
60  Show the :program:`lit` help message and exit.
64  Show :program:`lit`'s version number and exit.
103  Moreover, :program:`lit` inserts ``'RUN: at line N'`` before each
168  will cause the program to exit with a non-zero status.
170  When this option is enabled, :program:`lit` will also automatically provide a
177  enabled, :program:`lit` will also automatically provide a "``vg_leak``"
184  :program:`valgrind` itself.
368  Run :program:`lit` in debug mode, for debugging configuration issues and
369  :program:`lit` itself.
387 :program:`lit` will exit with an exit code of 1 if there are any FAIL or XPASS
389 for non-test related failures (for example a user error or an internal program
397 The inputs passed to :program:`lit` can be either individual tests, or entire
398 directories or hierarchies of tests to run.  When :program:`lit` starts up, the
402 In the :program:`lit` model, every test must exist inside some *test suite*.
403 :program:`lit` resolves the inputs specified on the command line to test suites
406 and as configuration files which :program:`lit` loads in order to understand
409 Once :program:`lit` has mapped the inputs into test suites it traverses the
415 interpreted.  In addition, :program:`lit` always identifies tests by the test
417 appropriately configured projects, this allows :program:`lit` to provide
476 This section describes the :program:`lit` testing architecture for users interested in
477 creating a new :program:`lit` testing implementation, or extending an existing one.
479 :program:`lit` proper is primarily an infrastructure for discovering and running
481 tests. :program:`lit` itself doesn't know how to run tests, rather this logic is
491 :program:`lit` identifies test suites as directories containing ``lit.cfg`` or
547  **root** The root configuration.  This is the top-most :program:`lit` configuration in
560 Once test suites are located, :program:`lit` recursively traverses the source
561 directory (following *test_source_root*) looking for tests.  When :program:`lit`
578 When :program:`lit` loads a subdirectory in a test suite, it instantiates a
581 test configuration is cloned :program:`lit` checks for a *lit.local.cfg* file
591 :program:`lit` allows patterns to be substituted inside RUN commands. It also
653 The :program:`lit` output for a test run conforms to the following schema, in
705 For convenience :program:`lit` automatically adds **available_features** for
708 :program:`lit` adds a feature based on the operating system being built on, for
709 example: `system-darwin`, `system-linux`, etc. :program:`lit` also
713 When building with sanitizers enabled, :program:`lit` automatically adds the
722 The :program:`lit` distribution contains several example implementations of