Il 23/04/2014 19:39, Aaron Ballman ha scritto: > On Wed, Apr 23, 2014 at 1:34 PM, Abramo Bagnara > <[email protected]> wrote: >> Il 23/04/2014 19:15, Delesley Hutchins ha scritto: >>> If gcc is indeed attempting to call the destructor anyway, wouldn't >>> declaring it public, but without a definition, just result in a link >>> error? The only option I can think of is to define delete, but throw a >>> hard error, thus turning a compile-time error into a run-time error. >>> >>> This sounds like a bug in gcc. After all, the purpose here is to >>> ensure that the destructor is never called, so I don't understand why >>> gcc would be trying to call it. >> >> According to standard, compiler is legitimate to call operator delete if >> object initialization fails with an exception. > > Does sufficient usage of noexcept cause the compile errors to go away? > If so, we could add LLVM_NOEXCEPT to Compiler.h, then make use of that > here to get the REQUIRES_EH=1 build going again.
No, it is not enough: gcc asks for an accessible operator delete also if constructors are declared with noexcept or throw(). > >> Are you contrary as a workaround to restore compilability with >> REQUIRES_EH=1 to move it to public area but to leave it deleted? > > That wouldn't work (and it would go against developer policy) because > LLVM_DELETED_FUNCTION is a noop for compilers which don't support > explicit delete (such as MSVC 2012). I'm aware of that, but, as this would lead to a compilation failure on most build machine, a mistaken commit would not pass unnoticed. -- Abramo Bagnara BUGSENG srl - http://bugseng.com mailto:[email protected] _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
