Build failure using REQUIRES_EH=1 after r205915

[Abramo Bagnara]

Il 23/04/2014 19:39, Aaron Ballman ha scritto:
> On Wed, Apr 23, 2014 at 1:34 PM, Abramo Bagnara
> <abramo.bagnara at bugseng.com> 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:abramo.bagnara at bugseng.com