catch(…) swallowing all other catches in xcode llvm 3.0

Question

I'm trying to get googletest to run on my c++ project, and part of this involves using EXPECT_THROW(statement, expected_exception);. I'm using XCode with the "Apple LLVM Compiler 3.0" selected. All this is on Snow Leopard 10.6.8, XCode 4.2.

I could not get any of these tests to pass, even when using the explicit dummy case EXPECT_THROW(throw std::runtime_error(), std::runtime_error);

After expanding the macro (from gtest/internal/gtest-internal.h:1114 GTEST_TEST_THROW_) myself to

    bool gtest_caught_expected = false;
    try {
        // GTEST_SUPPRESS_UNREACHABLE_CODE_WARNING_BELOW_(statement);
        throw std::runtime_error("sigh");
    }
    // catch (expected_exception const&) {
    catch (std::runtime_error const& e){
        std::cout << "const ref caught" << std::endl;
        gtest_caught_expected = true;
    }
    // added by me to check it wasn't a const& issue
    catch (std::runtime_error e){
        std::cout << "type caught" << std::endl;
        gtest_caught_expected = true;
    }
    catch (...) {
        //gtest_msg.value =
        // "Expected: " #statement " throws an exception of type "
        //#expected_exception ".\n  Actual: it throws a different type.";
        //goto GTEST_CONCAT_TOKEN_(gtest_label_testthrow_, __LINE__);
        std::cout << "unknown caught" << std::endl;         
    }

then setting a break point in gdb with catch catch and stepping through, I can see that the catch(runtime_errors) are skipped, and the catch(...) is being executed. If I comment out the catch(...) block then the correct catch(std::runtime_error const& e) statement is executed.

Setting my compiler to "LLVM GCC 4.2" fixes the issue but I want to target clang++.

My separate EXPECT_THROW test case works when compiled manually with clang++ on the command line so I figure it must be some esoteric xcode or llvm setting? Or maybe some how LLVM is monkey wrenching my runtime_error into some other type? I tried a catch throw but could get any type information in that context.

Anyone experienced this before or have any ideas?

EDIT:

So I was also linking with libprofile_rt.dylib, along with the compiler flags -fprofile-arcs -fprofile-coverage. Removing the compiler flag -fprofile-arcs removed the issue. Annyoing because it breaks my coverage reports.

(Linking with librpofile_rt.a had the same issues)

Surely I'm not the only one to see this since LLVM supposedly uses googletest for their testcases?!

Unsure if I should post this as the answer or if someone more knowledgable may come along and provide a real solution.

Answer 1

After waiting a bit it looks like there isn't a known fix for this so I'll post my answer as above. It might be fixed in Xcode 4.3

So I was also linking with libprofile_rt.dylib, along with the compiler flags -fprofile-arcs -fprofile-coverage. Removing the compiler flag -fprofile-arcs removed the issue. Annyoing because it breaks my coverage reports.

(Linking with librpofile_rt.a had the same issues)

Surely I'm not the only one to see this since LLVM supposedly uses googletest for their testcases?!