поймать (...) проглотить все другие ловит в Xcode llvm 3.0 - PullRequest
3 голосов
/ 29 марта 2012

Я пытаюсь запустить googletest в моем проекте c ++, и часть этого включает использование EXPECT_THROW(statement, expected_exception);. Я использую XCode с выбранным «Apple LLVM Compiler 3.0». Все это на Snow Leopard 10.6.8, XCode 4.2.

Я не смог пройти ни один из этих тестов, даже при использовании явного фиктивного регистра EXPECT_THROW(throw std::runtime_error(), std::runtime_error);

После расширения макроса (из gtest / internal / gtest-internal.h: 1114 GTEST_TEST_THROW_) до

    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;         
    }

затем, установив точку останова в gdb с помощью catch catch и пройдя по ней, я вижу, что catch(runtime_errors) пропущены, а catch(...) выполняется. Если я закомментирую блок catch(...), будет выполнен правильный оператор catch(std::runtime_error const& e).

Установка моего компилятора на "LLVM GCC 4.2" устраняет проблему, но я хочу нацелиться на clang ++.

Мой отдельный тестовый пример EXPECT_THROW работает, когда он скомпилирован вручную с помощью clang ++ в командной строке, поэтому я полагаю, что это должна быть какая-то эзотерическая настройка xcode или llvm? Или, может быть, каким-то образом LLVM превращает обезьяну в мой runtime_error в какой-то другой тип? Я попытался catch throw, но мог получить любую информацию о типе в этом контексте.

Кто-нибудь испытывал это раньше или есть идеи?

EDIT:

Так что я также связывался с libprofile_rt.dylib вместе с флагами компилятора -fprofile-arcs -fprofile-coverage. Снятие флага компилятора -fprofile-arcs устранило проблему. Раздражает, потому что это нарушает мои отчеты о покрытии.

(У связи с librpofile_rt.a были те же проблемы)

Конечно, я не единственный, кто это видит, поскольку LLVM предположительно использует googletest для своих тестовых случаев?!

Не уверен, стоит ли мне публиковать это как ответ или если кто-то более знающий может прийти и предложить реальное решение.

1 Ответ

0 голосов
/ 05 апреля 2012

После небольшого ожидания кажется, что это неизвестно, поэтому я опубликую свой ответ, как указано выше.Это может быть исправлено в Xcode 4.3

Так что я также связывался с libprofile_rt.dylib вместе с флагами компилятора -fprofile-arcs -fprofile-покрытие.Снятие флага компилятора -fprofile-arcs устранило проблему.Раздражает, потому что это нарушает мои отчеты о покрытии.

(У связи с librpofile_rt.a были те же проблемы)

Конечно, я не единственный, кто видит это, поскольку LLVM предположительно использует googletest для своих тестовых случаев.?!

...