[Bug c++/96090] noexcept operator of potentially-throwing defaulted function gives the wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96090 Johel Ernesto Guerrero Peña changed: What|Removed |Added Known to fail||10.3.0, 11.2.0, 12.0 Keywords||rejects-valid Summary|Inconsistent querying of|noexcept operator of |differring exception|potentially-throwing |specifications of |defaulted function gives |explicitly defaulted|the wrong result |functions | --- Comment #1 from Johel Ernesto Guerrero Peña --- Now they all give the wrong answer: https://godbolt.org/z/hroWqTExz.
[Bug c++/96090] noexcept operator of potentially-throwing defaulted function gives the wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96090 --- Comment #3 from GCC Commits --- The master branch has been updated by Nathaniel Shead : https://gcc.gnu.org/g:4719b6f5ae4d758f193a17bbd5fb6cbacd702a23 commit r14-6395-g4719b6f5ae4d758f193a17bbd5fb6cbacd702a23 Author: Nathaniel Shead Date: Sat Oct 28 16:04:52 2023 +1100 c++: Fix noexcept checking for trivial operations [PR96090] This patch stops eager folding of trivial operations (construction and assignment) from occurring when checking for noexceptness. This was previously done in PR c++/53025, but only for copy/move construction, and the __is_nothrow_xible builtins did not receive the same treatment when they were added. To handle `is_nothrow_default_constructible`, the patch also ensures that when no parameters are passed we do value initialisation instead of just building the constructor call: in particular, value-initialisation doesn't necessarily actually invoke the constructor for trivial default constructors, and so we need to handle this case as well. This is contrary to the proposed resolution of CWG2820; for now we just ensure it matches the behaviour of the `noexcept` operator and create testcases formalising this, and if that issue gets accepted we can revisit. PR c++/96090 PR c++/100470 gcc/cp/ChangeLog: * call.cc (build_over_call): Prevent folding of trivial special members when checking for noexcept. * method.cc (constructible_expr): Perform value-initialisation for empty parameter lists. (is_nothrow_xible): Treat as noexcept operator. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/noexcept81.C: New test. * g++.dg/ext/is_nothrow_constructible7.C: New test. * g++.dg/ext/is_nothrow_constructible8.C: New test. Signed-off-by: Nathaniel Shead
[Bug c++/96090] noexcept operator of potentially-throwing defaulted function gives the wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96090 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- Fixed, I guess.
[Bug c++/96090] noexcept operator of potentially-throwing defaulted function gives the wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96090 Nathaniel Shead changed: What|Removed |Added CC||nathanieloshead at gmail dot com --- Comment #2 from Nathaniel Shead --- I'm working on a patch for this. But worth noting... > static_assert(!is_nothrow_default_constructible_v); I'm not sure this is correct. By https://eel.is/c++draft/meta.unary.prop#9 this is testing noexceptness of value-initialisation. And https://eel.is/c++draft/dcl.init.general#9.1 says > if T has either no default constructor ([class.default.ctor]) or >a default constructor that is user-provided or deleted, then >the object is default-initialized; > otherwise, the object is zero-initialized and the semantic constraints >for default-initialization are checked, and if T has a non-trivial >default constructor, the object is default-initialized; Since the default constructor here is not user-provided, and also trivial, the object should not be default-initialized and thus the default constructor is not called, and thus this is not potentially-throwing.
