> From: David Malcolm <dmalc...@redhat.com>
> Sent: Thursday, October 24, 2019 11:18 PM
> On Thu, 2019-10-24 at 20:50 +0000, Andrew Dean via gcc wrote:
> Thanks for your email, it looks interesting. Is your code somewhere we can
> see
> it?
It can be -- what is the preferred way to share the code? Though to be honest I
can summarize the changes pretty quickly:
1. Add catch.hpp (the single include header from the Catch2 project) and a
small wrapper header around catch.hpp that temporarily fixes up some macros
that GCC defines to replace c library functions and does nothing if !CHECKING_P
2. Modify test methods like so:
- void test_this_thing ()
+ TEST_CASE("test this thing")
And
- ASSERT_EQ (a, b);
+ REQUIRE (a == b);
3. Invoke the Catch2 test runner during selftest like:
Catch::Session ().run ();
4. Remove the manual invocations of the test methods, as the TEST_CASE macro
takes care of self-registration.
> I think the consensus during review was that I was over-engineering things,
> and
> that each iteration from v1 to v8 made the code simpler and involved less C++
> "magic", closer to C. Whether that's still the consensus I don't know.
> Different
> people within the GCC dev community have different comfort levels with C++,
> and my initial version (using
> gtest) was probably too "magic" for some. Maybe people here are more
> comfortable with C++ now?
Here's hoping! Looks like you had a very similar starting point as what I
suggested here.
> GCC has some rather unique requirements, in that we support a great many
> build configurations, some of which are rather primitive - for example,
> requiring just C++98 with exceptions disabled, in that we want to be able to
> be
> bootstrappable on relatively "ancient" configurations.
> IIRC auto-registration of tests requires that the build configuration have a
> sufficiently sane implementation of C++ - having globals with non-trivial
> ctors
> tends to be problematic when dealing with early implementations of C++.
Is C++98 the limit of what we can use in GCC? If so, that immediately
eliminates Catchv1 (C++03), Catch2 (C++11+) and GTest (C++11)
> Personally I don't find the manual registration of tests to be a pain, but it
> would
> be nice to have more readable errors on failures. There's probably a case for
> more verbose test output. (generally I immediately just do "make
> selftest-gdb"
> on failures; the issue is if it suddenly starts failing on a build I don't
> have access
> to)
I didn't know about selftest-gdb. That will come in handy. My ideal programming
style, is to write a new test, watch it fail for the expected reason, then
write the production code to make it pass. Having to attach a debugger to
validate/investiigate failures slows down the process, as does having to write
the additional code to invoke the new test methods, if only by a little bit.
> I suspect that exceptions would be a deal-breaker; does Catch2 support -fno-
> exceptions?
Yes, Catch2 supports -fno-exceptions, though not like GTest, which was built to
not use exceptions at all. Catch2 stops running tests at the first failure and
gives the output as shown in the original email.
> As for setup/teardown, I've been able to do that "manually" using RAII- style
> classes in test functions.
Yes, I have added some RAII classes to assist in testing as well. I just think
it will be even better if it were easier to do.
