| Message ID | 20170206171331.GB13736@redhat.com |
|---|---|
| State | New |
| Headers | show |
On Mon, Feb 6, 2017 at 12:13 PM, Marek Polacek <polacek@redhat.com> wrote: > This patch adds a description of something I noticed while doing the > Fedora mass rebuild. Do we want to say more about the invalidity of > the incomplete type case? Here's the relevant rule in the standard: 14.6/8: "If a hypothetical instantiation of a template immediately following its definition would be ill-formed due to a construct that does not depend on a template parameter, the program is ill-formed; no diagnostic is required. If the interpretation of such a construct in the hypothetical instantiation is different from the interpretation of the corresponding construct in any actual instantiation of the template, the program is ill-formed; no diagnostic is required. [ Note: This can happen in situations including the following: * a type used in a non-dependent name is incomplete at the point at which a template is defined but is complete at the point at which an instantiation is performed, ...." > Furthermore I noticed that the testcase below doesn't compile anymore since > r240874; Nathan, is that desirable? > > class C { > public: > virtual ~C() noexcept(false); > }; > class A : virtual C { > virtual C m_fn1() = 0; > }; > class B : A {}; > > s.cc:8:7: error: looser throw specifier for ‘virtual B::~B() noexcept (false)’ > class B : A {}; > ^ > s.cc:5:7: error: overriding ‘virtual A::~A() noexcept’ > class A : virtual C { > ^ No, this is a bug. Jason
On 2017.02.06 at 18:13 +0100, Marek Polacek wrote: > This patch adds a description of something I noticed while doing the > Fedora mass rebuild. Do we want to say more about the invalidity of > the incomplete type case? > +<p> > +GCC 7 no longer accepts ill-formed code involving use of an incomplete type: > +<pre><code> > +namespace N { > +class C; > +class A { > + C fn1(); > +}; > +template <typename> class B : A { > + void fn2() { fn1().x; } > +}; > +} > +</code></pre> > +</p> > + You could drop the namespace. Also "struct A" would be better, because otherwise fn1 is a private and thus unaccessible in fn2. You could also mention Chromium and Node.js as prominent examples.
On 02/06/2017 01:03 PM, Jason Merrill wrote:
> No, this is a bug.
Yup.
On Mon, Feb 06, 2017 at 03:00:38PM -0500, Nathan Sidwell wrote: > On 02/06/2017 01:03 PM, Jason Merrill wrote: > > > No, this is a bug. > > Yup. I've opened PR79393. Marek
Index: gcc-7/porting_to.html =================================================================== RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/porting_to.html,v retrieving revision 1.3 diff -u -r1.3 porting_to.html --- gcc-7/porting_to.html 3 Feb 2017 07:55:27 -0000 1.3 +++ gcc-7/porting_to.html 6 Feb 2017 17:08:44 -0000 @@ -33,6 +33,23 @@ <h2 id="cxx">C++ language issues</h2> +<h3 id="incomplete-type">Invalid use of incomplete type</h3> + +<p> +GCC 7 no longer accepts ill-formed code involving use of an incomplete type: +<pre><code> +namespace N { +class C; +class A { + C fn1(); +}; +template <typename> class B : A { + void fn2() { fn1().x; } +}; +} +</code></pre> +</p> + <h3 id="conversion-op-mangling">Mangling change for conversion operators</h3> <p>
This patch adds a description of something I noticed while doing the Fedora mass rebuild. Do we want to say more about the invalidity of the incomplete type case? Furthermore I noticed that the testcase below doesn't compile anymore since r240874; Nathan, is that desirable? class C { public: virtual ~C() noexcept(false); }; class A : virtual C { virtual C m_fn1() = 0; }; class B : A {}; s.cc:8:7: error: looser throw specifier for ‘virtual B::~B() noexcept (false)’ class B : A {}; ^ s.cc:5:7: error: overriding ‘virtual A::~A() noexcept’ class A : virtual C { ^ If it's desirable that g++ rejects this, we should say something about it in porting_to. Any ideas what that might be? Thanks, Marek