Bug 51452 - [DR 2116] is_nothrow_.*constructible bugs
Summary: [DR 2116] is_nothrow_.*constructible bugs
Status: SUSPENDED
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 4.7.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 54722 56191 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-12-07 16:55 UTC by Dave Abrahams
Modified: 2016-12-01 14:00 UTC (History)
6 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2011-12-09 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Abrahams 2011-12-07 16:55:00 UTC
The traits that detect nothrow constructibility are buggy because they are influenced by whether the object has a nothrow dtor; destruction is invoked at the end of evaluation of the full expression in the noexcept( ... ) operator.  They all use the pattern of constructing a temporary inside noexcept, whereas they should be using placement new:


  struct X
  {
      X() noexcept;
      ~X();
  };

  static_assert( noexcept( X() ), "fails because of ~X" );
  static_assert( noexcept(new (nullptr) X()), "works" );
Comment 1 Jonathan Wakely 2011-12-07 17:16:58 UTC
I think this is by design, see the thread beginning with c++std-lib-30698

I've been surprised by that reasoning several times e.g. http://gcc.gnu.org/ml/gcc-help/2011-11/msg00015.html
Comment 2 Paolo Carlini 2011-12-07 17:20:47 UTC
Daniel should resolve this.
Comment 3 Paolo Carlini 2011-12-07 17:32:54 UTC
By the way, Jon, I think we should audit the library a little more systematically vs PR50043 (assuming that, unfortunately, isn't done in time for 4.7) and in case add explicit noexcept.
Comment 4 Jonathan Wakely 2011-12-07 17:38:39 UTC
yes, I keep forgetting that noexcept should be implied on dtors now
Comment 5 Dave Abrahams 2011-12-07 18:41:12 UTC
(In reply to comment #1)
> I think this is by design, see the thread beginning with c++std-lib-30698
> 
> I've been surprised by that reasoning several times e.g.
> http://gcc.gnu.org/ml/gcc-help/2011-11/msg00015.html

I see the thread.  I don't see anything in the thread that supports the idea that it should behave this way, but maybe I'm missing something.
Comment 6 Jonathan Wakely 2011-12-07 19:03:30 UTC
c++std-lib-30708 has Daniel's explanation of his interpretation, as implemented in GCC.

FWIW I prefer your interpretation, but will peace Daniel to comment further
Comment 7 Daniel Krügler 2011-12-09 15:57:15 UTC
Please note that this issue here is a simply a dup of bug 51295, which is a compiler defect and *not* a library problem. See [class.dtor] p3:

"A declaration of a destructor that does not have an exception-specification is implicitly considered to have the same exception-specification as an implicit declaration (15.4)."

I hadn't looked at the actual example until Dave was describing effects on the LWG reflector that are obviously in contradiction to the core language.

I repeat: The test case should be well-formed with the existing is_constructible definition once the compiler defect is fixed.
Comment 8 Jonathan Wakely 2011-12-09 16:02:11 UTC
Corrected testcase:

  struct X
  {
      X() noexcept;
      ~X() noexcept(false);
  };

  static_assert( noexcept( X() ), "fails because of ~X" );
  static_assert( noexcept(new (nullptr) X()), "works" );
Comment 9 Paolo Carlini 2011-12-09 16:03:29 UTC
Ah good, let's resolve as duplicate then. Thanks Daniel.

*** This bug has been marked as a duplicate of bug 51295 ***
Comment 10 Dave Abrahams 2011-12-09 18:11:41 UTC
(In reply to comment #9)
> Ah good, let's resolve as duplicate then. Thanks Daniel.
> 
> *** This bug has been marked as a duplicate of bug 51295 ***

But wait!  The example I gave was not a test case!  The point was that it shows a defect in traits that detect nothrow constructibility.  This bug should be re-opened.
Comment 11 Jonathan Wakely 2011-12-09 18:26:57 UTC
Agreed (though it should probably be suspended when there's an LWG issue)

My "corrected" testcase wasn't right, here's another attempt:

#include <type_traits>

struct X
{
    X() noexcept;
    ~X() noexcept(false);
};

static_assert(std::is_nothrow_constructible<X>::value, "fails because of ~X");
Comment 12 Paolo Carlini 2011-12-09 18:37:37 UTC
Thus Daniel was wrong when he said that fixing 51295 automatically renders correct his current implementation of the trait? I suspect there is a misunderstanding here: we are in control of both compiler and library, thus, if I understood Daniel correctly, there is no need to keep this issue open, as if to force some sort of workaround on the library side. Unless we *really* decide that we don't want to wait for the front-end to be fixed. Anyway, I'm off, anything Daniel wants to do for his trait, it's Ok with me.
Comment 13 Jonathan Wakely 2011-12-09 19:32:28 UTC
The issue is what the "correct" definition of the trait is, but I think we need a DR to clarify it
Comment 14 Jonathan Wakely 2012-08-12 18:14:43 UTC
This is http://cplusplus.github.com/LWG/lwg-active.html#2116 so let's suspend this.
Comment 15 Paolo Carlini 2012-09-26 23:13:59 UTC
*** Bug 54722 has been marked as a duplicate of this bug. ***
Comment 16 Antony Polukhin 2013-02-04 07:29:16 UTC
*** Bug 56191 has been marked as a duplicate of this bug. ***