[m-rev.] tests/invalid failures for non-C grades
Zoltan Somogyi
zoltan.somogyi at runbox.com
Sat Sep 13 14:33:16 AEST 2025
In non-C grades, tests/invalid test cases are handled via mmc --make,
via this mmake rule:
# XXX: the reason we run the $(MCM) command twice is to avoid doubled up
# error messages, once while making interface files, then the module proper.
# The second time the command is run, only one set of error messages
# should appear.
$(NONSPECIAL_PROGS:%=%.err):
-$(MCM) $@
if $(MCM) -r $@ > /dev/null 2>&1 ; \
then false; \
else true; \
fi
The intention here is that
- the first MCM (mmc --make) builds all the needed interface files
and then fails, having created the wrong output; while
- the second MCM just uses those interface files.
However, this does not really work, because the second MCM specifies
the -r (rebuild) option. This includes rebuilding all buildable files, *including*
interface files. So some test case failures in non-C grades are caused by
the test case putting into the .err file the output of mmc --make-interface,
NOT the output of mmc --errorcheck-only.
I see two ways to fix these test failures. Both involve splitting
NONSPECIAL_PROGS into two halves, consisting of the tests that fail
for the above reason (call these the interface error test cases), and all others.
- The first way is to add another rule for the interface error test cases
that uses explicit invocations of mmc --make-interface (and --make-short-interface)
to build the .int* files, and then invokes MCM without -r to create the .err
file (doing the just the job of mmc --errorcheck-only).
- The second way is to simply move the interface error test cases to
invalid_make_int.
The second way is simpler, but it tests only the errors that the compiler
detects during mmc --make-interface.
I propose to split each of the currently failing test cases into two parts:
the part containing the errors we detect during mmc --make-interface,
and the rest. I would then move the first parts to invalid_make_int, and
keep the second parts here in invalid (if they are not empty).
Does anyone object to this plan?
Zoltan.
More information about the reviews
mailing list