Structure of the LuaJIT test suite

test

Test correctness/expected behaviour of LuaJIT.

• libs: contains tests per library of the basic Lua libraries
  • core: basic (core) functions (print(), pairs(), assert(), ...)
  • coroutine
  • debug
  • io
  • math
  • os
  • package
  • string
  • table
• libs_ext: the libraries provided by LuaJIT, as well as the extensions to the core libraries (e.g. table.new()) and to the basic functions (e.g. xpcall() behaviour). ffi will be huge as it should basically test a C compiler; perhaps this should be split off in a separate directory.
  • core: test LuaJIT's enhancements of e.g. xpcall(), tostring(), tonumber()
  • bit
  • ffi
  • jit
  • debug
  • io
  • math
  • string
  • table
  • ...
• lang: language concepts such as coercion, scoping rules, closures, short circuit logic, varargs, order of assignments.
• gc: garbage collector
• parser
• capi: all functions of the C API.
• capi_ext: LuaJIT's extensions to the C API.

jit

Tests for the JIT compiler (correctness + internals (how?))

• ir: tests for the the intermediate representation
• opt: LuaJIT optimizations, such as ABC elimination, allocation sinking, etc. Should test correctness as well as check if the optimization actually occurs.
• ...

standalone

Test the standalone LuaJIT interpreter's command line options.

bench

Performance and memory usage benchmarks.

NOTE from Mike Pall: libs violates the don't-pluralize-the-names-of-aggregates rule. Also, separating extensions into a different tree seems artificial and hard to do consistently. And it might prove not to be that helpful in the long run. Where do you put a test that needs an extended functionality (like the FFI) to test a core functionality (like the string/number conversions)?