Page MenuHomePhabricator

Tests for strings conversions under libcpp-no-exceptions
ClosedPublic

Authored by rogfer01 on Oct 31 2016, 3:52 AM.

Details

Summary

These files have two styles of tests

// First style
try {
  action
  assert(something-expected);
} catch ( exception ) {
  assert(false);
}

// Second style
try {
  action
  assert(false);
} catch ( exception ) {
  assert(something-expected);
}

Under libcpp-no-exceptions, we still want to run what is inside the try
block (but not the catch) for first style tests. Second style tests are
skipped as a whole.

Conversions from integers only feature second style tests.

The diff is a bit noisy because it still has to skip try keywords
for first style tests. I prefer this to adding a magical TEST_TRY macro
here (catch blocks would look weird and introducing a TEST_CASE macro
does not look appealing to me either)

Diff Detail

Repository
rL LLVM

Event Timeline

rogfer01 updated this revision to Diff 76373.Oct 31 2016, 3:52 AM
rogfer01 retitled this revision from to Tests for strings conversions under libcpp-no-exceptions .
rogfer01 updated this object.
rogfer01 added reviewers: mclow.lists, EricWF, rmaprath.
rogfer01 added a subscriber: cfe-commits.
rmaprath edited edge metadata.Nov 2 2016, 3:00 AM

Would it be more cleaner to separate out the exceptions-related tests into their own functions? So, we'd have the two functions test_withexceptions() and test_noexceptions(); the former will only be invoked when testing the normal library variant, the latter will be invoked for all the library variants.

WDYT?

/ Asiri

EricWF added inline comments.Nov 4 2016, 6:36 PM
test/std/strings/string.conversions/stold.pass.cpp
39 ↗(On Diff #76373)

Hmm. All of these #ifdefs get ugly fast. I think it might be better to add TEST_TRY and TEST_CATCH(...) macros defined like:

#ifndef TEST_HAS_NO_EXCEPTIONS
#define TEST_TRY try
#define TEST_CATCH(...) catch(__VA_ARGS__)
#else
#define TEST_TRY
#define TEST_CATCH(...) if (false)
#endif

What do you think? Feel free to add those macros to test_macros.h if you like the idea.

mclow.lists edited edge metadata.Nov 5 2016, 9:33 PM
I think it might be better to add TEST_TRY and TEST_CATCH(...) macros defined like

@rogfer01 said at the top that he didn't want to add "a magical TEST_TRY macro" - and I agree. Someone tried that in another review, and I nixed it there.

I think it might be better to add TEST_TRY and TEST_CATCH(...) macros defined like

@rogfer01 said at the top that he didn't want to add "a magical TEST_TRY macro" - and I agree. Someone tried that in another review, and I nixed it there.

I had a proposal for something along those lines in D14653, however those TEST_TRY and TEST_CATCH macros were trying to be "too smart".

I agree, having macros for try and catch sounds to me like it would set the wrong precedent.

I'd rather not to go the way of TEST_TRY and TEST_CASE macros.

As suggested by @rmaprath, I've been playing with grouping the tests in three categories: no exceptions (at all), should not throw, must throw. No changes are required for the first group. The third group is easy to protect with just a couple of ifdef / endif. The second group is the noisiest as we still want to run the code inside the try but we need to skip the try keyword and the catch handlers. This approach may be a bit cleaner.

Any further suggestion? I plan to update the patch with the strategy above if no objections arise.

EricWF accepted this revision.Nov 14 2016, 1:41 AM
EricWF edited edge metadata.

LGTM. The consensus is against adding TEST_TRY and TEST_CATCH.

This revision is now accepted and ready to land.Nov 14 2016, 1:41 AM
This revision was automatically updated to reflect the committed changes.