* tests: extend ternary test to cover bugs
See issues #5003, #3690, and #2404
* mparser: store subdir in ternary node
Ternaries don't really need subdirs, but they can be passed into
functions that expect the type they're provided to have a
subdir. Provide it to fulful the interface.
Fixes#5003Fixes#3690Fixes#2404
This provides an initial support for parsing TAP output. It detects failures
and skipped tests without relying on exit code, as well as early termination
of the test due to an error or a crash.
For now, subtests are not recorded in the TestRun object. However, because the
TAP output goes on stdout, it is printed by --print-errorlogs when a test does
not behave as expected. Handling subtests as TestRuns, and serializing them
to JSON, can be added later.
The parser was written specifically for Meson, and comes with its own
test suite.
Fixes#2923.
Hard errors also come from the GNU Automake test protocol. They happen when
e.g., the set-up of a test case scenario fails, or when some
other unexpected or highly undesirable condition is encountered.
TAP will use them for parse errors too. Add them to the exitcode protocol
first.
--print-errorlogs is using the test's return code to look for failed
tests, instead of just looking at the TestResult. Simplify the code and
make it work for TAP too.
Before, the logic initialization compiler options from environment
variables vs config files was strewn about. Now, it is consolidated. We
leverage the new `envconfig.py` module to expose the configuration data
to `compilers.py` without creating an import cycle.
1. They (and the others) all use PerMachineDefaultable. It's not the
best class, but consistency come first. (It and all of them can be
improved accross the board later.)
2. They use `None` as the default argument so as not to mutate what's
effectively a global variables. (Thanks @dcbaker!)
3. They have a `fallback` field to centralize authority on when
environment variables should be consulted.
First of all, I'd like compilers and other modules that environment.py
currently imports to be able to take these without creating
hard-to-follow module cycles.
Second of all, environment.py's exact purpose seems a bit obscured.
Splitting the data types (and basic pure functions) from the more
complex logic that infers that data seems like a good way to separate
concerns.
Daniel Mensinger
Jussi Pakkanen
Dylan Baker
Steve Lhomme
Paolo Bonzini
Daniel Schulte
Daniel Schulte
Nicolas Schneider
Michael Hirsch, Ph.D
John M. Lindemon
John Ericson
Olexa Bilaniuk