BSLS_ASSERT_SAFE_IS_ACTIVE confusion

[seanbaxter]

Aside from the five line-number tests, I have one test remaining that breaks: bsls_asserttest.t.cpp case 8. My assumption is that it's a preprocessor problem on my end. But I can't diagnose the problem.

Line 2928 writes an error to the terminal: BSLS_ASSERTTEST_ASSERT_OPT_FAIL(Production::callAssertSafe(true));

callAssertSafe expands BSLS_ACTIVE_SAFE. That was apparently expanding to no code--I couldn't understand it at all, so I actually wrote a new preprocessor directive #print_macro to print the definition of a macro. Lo and behold, it was set to BSLS_ASSERT_DISABLED_IMP!

bsls_assert.h:1329 shows the solution, which is to define BSLS_ASSERT_SAFE_IS_ACTIVE prior to include bsls_assert.h. That seems easy enough, except bsls_asserttest.t.cpp:2825 #errors when that macro is defined!

How is one supposed to use BSLS_ASSERTTEST_ASSERT_OPT_FAIL in conjunction with BSLS_ACTIVE_SAFE to raise an exception? Whatever I try either raises a preprocessor error within the test or else results in a disabled BSLS_ACTIVE_SAFE.

[notadragon]

The testing this component does is definitely confusing, but what it is doing in the block in question is verifying that the BSLS_ASSERTTEST_ASSERT_OPT_FAIL macro detects that "Production::callAssertsafe(true)" DOESN'T fail. In this case, it shouldn't fail because the bsls_assert.h header has been included after only defining BDE_BUILD_TARGET_SAFE_2 and BSLS_ASSERT_LEVEL_ASSERT_OPT.

Note that this test driver, along with the review and assert test drivers, is verifying that the macros behave correctly in many different scenarios by repeatedly re-including them.

The test driver in question will trigger a lot of errors being written to the terminal. That is distinct form the test failing, which only happens when the test driver's ASSERT macro is called with false, which you'll see in the output as something like "Error ../../bde/groups/bsl/bsls/bsls_asserttest.t.cpp(3442): ... (failed)"

[notadragon]

Also note that this hooks into a locally-defined version of the ASSERT macro in this function, not the one that was declared at the top of thee test driver.

[seanbaxter]

It prints out "Expression passed that was expected to fail." You're saying that's not a failure?

[notadragon]

No, that's not a failure, the test driver is testing that the asserttest macro is detecting and reporting that failure correctly.

[seanbaxter]

Ok good to know. My actual problem is much further down then.

[seanbaxter]

My problem is at line bsls_asserttest.t.cpp:3041.

#define BSLS_ASSERT_ASSERT_IMP(X,LVL) do {                                    \
        if (BSLS_PERFORMANCEHINT_PREDICT_UNLIKELY(!(X))) {                    \
            BSLS_PERFORMANCEHINT_UNLIKELY_HINT;                               \
            BloombergLP::bsls::AssertViolation violation(                     \
                                                     #X,                      \
                                                     BSLS_ASSERTIMPUTIL_FILE, \
                                                     BSLS_ASSERTIMPUTIL_LINE, \
                                                     LVL);                    \
            BloombergLP::bsls::Assert::invokeHandler(violation);              \
        }                                                                     \
    } while (false)

#define BSLS_ASSERTTEST_BRUTE_FORCE_IMP(RESULT, LVL, EXPRESSION_UNDER_TEST) { \
    try {                                                                     \
        EXPRESSION_UNDER_TEST;                                                \
                                                                              \
        ASSERT(bsls::AssertTest::tryProbe(RESULT,LVL));                       \
    }                                                                         \
    catch (const bsls::AssertTestException& e) {                              \
        ASSERT(bsls::AssertTest::catchProbe(RESULT,                           \
                                            BSLS_ASSERTTEST_CHECK_LEVEL_ARG,  \
                                            LVL,                              \
                                            e,                                \
                                            __FILE__));                       \
    } 

Inside the try block in BSLS_ASSERTTEST_BRUTE_FORCE_IMP, Production::callAssertOpt throws ('F', 'O'). The catch block calls AssertTest::catchProbe. That walks to the end of the function without printing anything and returns true. (True is good right?) But the EXPECTED variable was set to false at line 3015, so the ASSERT call in the catch handler fails. I see aSsErT being entered with condition=true, so I assume the local ASSERT definition at line 2707 is being used, as that'll flip X before comparing to EXPECTED.

My frustration is that I can step all the way through this, and the results appear to match the code on the screen, but it returns true whereas EXPECTED is set to false.

Basic control flow questions:

1. When called from line 3041, Production::callAssertOpt(false) should throw, correct?
2. The exception should be caught by the catch block bsls_asserttest.h:398 and call into AssertTest::catchProbe.
3. AssertTest::catchProbe should return true, because the thrown exception is well-formed.
4. The ASSERT macro defined at bsls_asserttest.t.cpp:2707 flips the true code to false, compares to EXPECTED (which was set to FALSE at 3015), which yields true, then calls aSsErT with condition=true, which prints the diagnostic and breaks the runtime. with this message:

Error /home/sean/projects/bde2/groups/bsl/bsls/bsls_asserttest.t.cpp(3041): bsls::AssertTest::catchProbe('F', BSLS_ASSERTTEST_CHECK_LEVEL_ARG, 'O', e, _FILE (failed)

Any idea on which of these 4 steps is wrong? The invokeHandler call is certainly being made by way of that BSLS_ASSERT_ASSERT_IMP expansion that's part of BSLS_ASSERT_OPT in Production::callAssertOpt...

I don't know how to even figure out if this test failure is caused by a preprocessor bug or an exception handling bug. I'd almost always assume the latter, but in this case the throws and catches seem to line up.

[notadragon]

So the particular example you are calling out is the first one in a block where the tests are verifying the component-identification logic. Note that on lines 2999 and 3003 we have #line macros, and that sets the filename to be different than bsls_asserttest.t.cpp for the definition of Production that is being used at this point in the test.

So in this case, catchProbe should be returning false when it compares the filename it gets from the exception (which came from the expansion of FILE inside BSLS_ASSERTIMPUTIL_FILE in BSLS_ASSERT_OPT on line 2965 of bsls_asserttest.t.cpp and should have a value of "bsls_fictionaltestcomponent.t.cpp") to the filename it expects ("bsls_asserttest.t.cpp").

In other words, this exception should be ill-formed by design, and that is what the test is verifying. Given what you said, i'd look at either how you're handling #line or if you are expanding FILE at the right times.

[seanbaxter]

line -- that's certainly the issue. Thanks. It would have taken me days to consider that.