On Thursday, 25 May 2017 12:14:09 PDT René J. V. Bertin wrote: > Thiago Macieira wrote: > > It's a bug in your testing, because it sets QT_NO_EXCEPTIONS here with > > Clang. > No it's not, ditto for testing by others. In fact, your test is wrong > because it misses a detail: this concerns ObjC++.
You never mentioned ObjC++. However: $ clang -std=c++14 -fno-exceptions -I. -include QtCore/qglobal.h -fPIC -xobjective-c++ -c -o /dev/null - <<<' #ifndef QT_NO_EXCEPTIONS # error Was not defined #endif' [nothing] So it still works. I also tested four different Clang versions: 3.8, 3.9, 4.0 and trunk (5.0). What's more, this used to work when Clang 3.6 was current. It even used to work when 2.8 was current, because this has never needed updates. > See > http://releases.llvm.org/3.6.0/tools/clang/docs/ReleaseNotes.html#the-excep > tions-macro : > > It explains rather unambiguously that clang 3.6 and later set _EXCEPTIONS > `if C++ or ObjC exceptions are enabled` and that `To reliably test if C++ > exceptions are enabled, use _EXCEPTIONS && __has_feature(cxx_exceptions), > else things won’t work in all versions of Clang in Objective-C++ files.` We're testing __EXCEPTIONS, like we should. Please describe the environment in which: a) -fno-exceptions is active b) __EXCEPTIONS is defined Provide the full command-line and the compiler version. I still advise you to look into what's wrong with your testing, because I can't reproduce it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
