In general I'm much happier with this approach, and I think this series
is close to ready, but I want to bring up some questions that could use
wider discussion.
This patch adds a selftest.h/.c to gcc, with an API loosely
modelled on gtest (though without the use of CamelCase): it
supports enough of the gtest API to enable the tests that I
wrote to run with minimal changes.
Here there's a question of style. I don't want to approve or reject this
just now, I'd like to hear what others think. To my eyes this still
looks rather seriously overengineered. Plain gcc_assert and if (cond)
abort (); would work just fine for the tests IMO, it's what we have for
regular testcases where we don't distinguish between all sorts of
microscopic subtests, and any gcc_assert failure is easy enough to
debug, just load up cc1 into the debugger and run. I don't think we need
output for tests that are really just expected to pass always, all we
need is the build to stop if an internal error is detected.
If I'd written it I'd also have used a somewhat lower-tech approach for
the registration and running of tests, but once again I'd like to hear
from others.
For things like
+#define RUN_ALL_TESTS() \
+ ::selftest::run_all_tests ()
I don't see the point of the macro. Also, in [8/15]
+class gimple_test : public ::selftest::test
+{
+ protected:
+ void
+ verify_gimple_pp (const char *expected, gimple *stmt)
+ {
+ pretty_printer pp;
+ pp_gimple_stmt_1 (&pp, stmt, 0 /* spc */, 0 /* flags */);
+ EXPECT_STREQ (expected, pp_formatted_text (&pp));
+ }
+};
+
Why have the class rather than just a function? This sort of thing makes
me go "overuse of C++".
Bernd
