[Bug c++/49266] New: [C++0x] Another incomplete type regression with noexcept

[Bug c++/49266] New: [C++0x] Another incomplete type regression with noexcept

[marc.glisse at normalesup dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49266

           Summary: [C++0x] Another incomplete type regression with
                    noexcept
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: marc.glisse@normalesup.org


This is another case of noexcept specifications causing instanciations and
resulting in incomplete types (see PR c++/49107 for the first one). Reporting
against C++ instead of libstdc++ like 49107.

#include <utility>
#include <vector>

template <class Refs>
class Cell_attribute
{
    typedef typename Refs::Dart_handle           Dart_handle;
};

template < class Refs>
struct Combinatorial_map_base
{
    typedef Cell_attribute< Refs> X;
    typedef std::vector<X> Y;
    std::pair<Y,Y> m;
};

template < class Items_>
struct Combinatorial_map
: public Combinatorial_map_base< Combinatorial_map<Items_> >
{
    typedef int*       Dart_handle;
};

int main()
{
    typedef Combinatorial_map<void > Map2;
    Map2();
}



$ c++ -std=gnu++0x -Wall -c Combinatorial_map_test.cpp
Combinatorial_map_test.cpp: In instantiation of
'Cell_attribute<Combinatorial_map<void> >':
/tmp/gcc/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/type_traits:1013:68:
  instantiated from 'constexpr const bool
std::__is_assignable_helper<std::vector<Cell_attribute<Combinatorial_map<void>
>, std::allocator<Cell_attribute<Combinatorial_map<void> > > >&,
std::vector<Cell_attribute<Combinatorial_map<void> >,
std::allocator<Cell_attribute<Combinatorial_map<void> > > >&&>::value'
/tmp/gcc/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/type_traits:1018:12:
  instantiated from
'std::is_assignable<std::vector<Cell_attribute<Combinatorial_map<void> >,
std::allocator<Cell_attribute<Combinatorial_map<void> > > >&,
std::vector<Cell_attribute<Combinatorial_map<void> >,
std::allocator<Cell_attribute<Combinatorial_map<void> > > >&&>'
/tmp/gcc/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/type_traits:89:12:
  instantiated from
'std::__and_<std::is_assignable<std::vector<Cell_attribute<Combinatorial_map<void>
>, std::allocator<Cell_attribute<Combinatorial_map<void> > > >&,
std::vector<Cell_attribute<Combinatorial_map<void> >,
std::allocator<Cell_attribute<Combinatorial_map<void> > > >&&>,
std::__is_nt_assignable_impl<std::vector<Cell_attribute<Combinatorial_map<void>
>, std::allocator<Cell_attribute<Combinatorial_map<void> > > >&,
std::vector<Cell_attribute<Combinatorial_map<void> >,
std::allocator<Cell_attribute<Combinatorial_map<void> > > >&&> >'
/tmp/gcc/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/type_traits:1066:12:
  instantiated from
'std::is_nothrow_assignable<std::vector<Cell_attribute<Combinatorial_map<void>
>, std::allocator<Cell_attribute<Combinatorial_map<void> > > >&,
std::vector<Cell_attribute<Combinatorial_map<void> >,
std::allocator<Cell_attribute<Combinatorial_map<void> > > >&&>'
/tmp/gcc/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/type_traits:1097:12:
  instantiated from
'std::__is_nt_move_assignable_impl<std::vector<Cell_attribute<Combinatorial_map<void>
>, std::allocator<Cell_attribute<Combinatorial_map<void> > > >, false>'
/tmp/gcc/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/type_traits:1103:12:
  instantiated from
'std::is_nothrow_move_assignable<std::vector<Cell_attribute<Combinatorial_map<void>
>, std::allocator<Cell_attribute<Combinatorial_map<void> > > > >'
/tmp/gcc/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/type_traits:89:12:
  instantiated from
'std::__and_<std::is_nothrow_move_assignable<std::vector<Cell_attribute<Combinatorial_map<void>
>, std::allocator<Cell_attribute<Combinatorial_map<void> > > > >,
std::is_nothrow_move_assignable<std::vector<Cell_attribute<Combinatorial_map<void>
>, std::allocator<Cell_attribute<Combinatorial_map<void> > > > > >'
/tmp/gcc/inst/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/bits/stl_pair.h:167:7:
  instantiated from
'std::pair<std::vector<Cell_attribute<Combinatorial_map<void> >,
std::allocator<Cell_attribute<Combinatorial_map<void> > > >,
std::vector<Cell_attribute<Combinatorial_map<void> >,
std::allocator<Cell_attribute<Combinatorial_map<void> > > > >'
Combinatorial_map_test.cpp:15:20:   instantiated from
'Combinatorial_map_base<Combinatorial_map<void> >'
Combinatorial_map_test.cpp:19:8:   instantiated from 'Combinatorial_map<void>'
Combinatorial_map_test.cpp:28:10:   instantiated from here
Combinatorial_map_test.cpp:7:50: error: no type named 'Dart_handle' in 'struct
Combinatorial_map<void>'

[Bug c++/49266] [C++0x] Another incomplete type regression with noexcept

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49266

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org,
                   |                            |paolo.carlini at oracle dot
                   |                            |com

--- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-06-04 12:30:59 UTC ---
Thanks Marc. I guess we need a definitive word here about whether these are c++
front issues or unavoidable problems caused by the implementation of the traits
via sfinae. In the latter case we have unfortunately to be prepared to revert
all the noexcept work involving traits until we get front-end support. Very
sad, of course: personally, I didn't think sfinae-based techniques had serious
limitations besides access-control. Would be something worth popularizing, can
affect a lot of sfinae uses outside the library too, of course.

[Bug c++/49266] [C++0x] Another incomplete type regression with noexcept

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49266

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #2 from Jason Merrill <jason at gcc dot gnu.org> 2011-06-04 23:42:03 UTC ---
(In reply to comment #1)
> Thanks Marc. I guess we need a definitive word here about whether these are c++
> front issues or unavoidable problems caused by the implementation of the traits
> via sfinae.

This definitely is not a front end bug.

> In the latter case we have unfortunately to be prepared to revert
> all the noexcept work involving traits until we get front-end support. Very
> sad, of course: personally, I didn't think sfinae-based techniques had serious
> limitations besides access-control. Would be something worth popularizing, can
> affect a lot of sfinae uses outside the library too, of course.

I don't think this is a sfinae vs intrinsic traits issue; intrinsic traits
would do basically the same thing.  It's an issue of involving traits/sfinae in
function signatures so that we trigger more instantiations when considering a
function during overload resolution rather than later, when the function is
instantiated.  The idea about deferring instantiation of exception-specifiers
seems likely to address this for noexcept specifically, but there might be
similar issues caused by increased use of sfinae for selecting between
overloads.

*** This bug has been marked as a duplicate of bug 49107 ***