[Bug libstdc++/85965] [8 Regression] G++ gives cryptic error instead of incomplete type

2019-05-15 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85965

--- Comment #14 from Jonathan Wakely  ---
A new patch to fix this was posted to:
https://gcc.gnu.org/ml/gcc-patches/2019-05/msg00863.html

[Bug libstdc++/85965] [8 Regression] G++ gives cryptic error instead of incomplete type

2019-05-15 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85965

Jonathan Wakely  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #13 from Jonathan Wakely  ---
(In reply to Hedayat Vatankhah from comment #12)
> AFAIK, this is a completely valid C++ code,

I don't think that's actually clear.

The standard doesn't specify when the comparison object must be invocable, so I
think it's conforming (but not very user friendly) to reject that code, and the
original example in this bug report.

[Bug libstdc++/85965] [8 Regression] G++ gives cryptic error instead of incomplete type

2019-05-15 Thread hedayat.fwd at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85965

--- Comment #12 from Hedayat Vatankhah  ---
OK, I found the problem. Yes, the fix is included in 9.1.1. 
However, the fix assumes that the type must be complete when desctructor is
called, but unfortunately, this is a wrong assumption. AFAIK, this is a
completely valid C++ code, but cannot be compiled successfully:

foo.h:
---
class Bar
{
public:
struct Less
{
bool operator()(const Bar& lhs, const Bar& rhs) const;
bool operator()(const Bar* lhs, const Bar* rhs) const;
};
};

class Biz;

#include 

class Foo
{
public:
void do_something();
std::set _map;
};
---
test.cpp:
---
void tt()
{
Foo f;
f.do_something();
}

---
foo.cpp:
---

#include "foo.h"
#include "biz.h"

Foo::do_something()
{
// do an insert...
}

[Bug libstdc++/85965] [8 Regression] G++ gives cryptic error instead of incomplete type

2019-05-14 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85965

--- Comment #11 from Jonathan Wakely  ---
The example reported here is fixed in 9.1.0, if you have a different example
maybe there's a different problem.

[Bug libstdc++/85965] [8 Regression] G++ gives cryptic error instead of incomplete type

2019-05-14 Thread hedayat.fwd at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85965

--- Comment #10 from Hedayat Vatankhah  ---
Isn't it expected to be fixed in Gcc 9.1.1? It seems to still affect GCC 9.1.1
(Fedora 30)

[Bug libstdc++/85965] [8 Regression] G++ gives cryptic error instead of incomplete type

2019-05-07 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85965

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Jonathan Wakely  ---
Fixed for 8.4 too.

[Bug libstdc++/85965] [8 Regression] G++ gives cryptic error instead of incomplete type

2019-05-07 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85965

--- Comment #8 from Jonathan Wakely  ---
Author: redi
Date: Tue May  7 15:46:05 2019
New Revision: 270960

URL: https://gcc.gnu.org/viewcvs?rev=270960=gcc=rev
Log:
PR libstdc++/85965 delay static assertions until types are complete

The static assertions added for PR libstdc++/48101 were at class scope
and so were evaluated too eagerly, when it might not be possible to
determine whether the function objects are invocable with the key types.
The problematic cases are where the key type is not known to be
convertible to the argument type(s) of the function object until later,
after a type has been completed. Specifically, if the key type is a
pointer to a derived class and the function object's argument type is a
pointer to a base class, then the derived-to-base conversion is only
valid once the derived type is complete.

By moving the static assertions to the destructor they will only be
evaluated when the destructor is instantiated, at which point whether
the key type can be passed to the function object should be knowable.
The ideal place to do the checks would be only when the function objects
are actually invoked, but that would mean adding the checks in numerous
places, so the destructor is used instead.

The tests need to be adjusted because the "required from here" line is
now the location of the destructor, not the point of instantiation in
the test file. For the map and multimap tests which check two
specializations, the dg-error matching the assertion text matches both
cases. Also check the diagnostic output for the template arguments, to
ensure both specializations trigger the assertion.

Backport from mainline
2019-03-26  Jonathan Wakely  

PR libstdc++/85965
* include/bits/hashtable.h (_Hashtable): Move static assertions to
destructor so they are not evaluated until the _Key type is complete.
* include/bits/stl_tree.h (_Rb_tree): Likewise.
* testsuite/23_containers/set/85965.cc: New test.
* testsuite/23_containers/unordered_set/85965.cc: New test.
* testsuite/23_containers/map/48101_neg.cc: Replace "here" errors
with regexp matching the corresponding _Rb_tree specialization.
* testsuite/23_containers/multimap/48101_neg.cc: Likewise.
* testsuite/23_containers/multiset/48101_neg.cc: Remove "here" error.
* testsuite/23_containers/set/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_map/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_multimap/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_multiset/48101_neg.cc: Likewise.
* testsuite/23_containers/unordered_set/48101_neg.cc: Likewise.

Added:
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/set/85965.cc
  - copied, changed from r270959,
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/map/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/unordered_set/85965.cc
  - copied, changed from r270959,
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/map/48101_neg.cc
Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/include/bits/hashtable.h
branches/gcc-8-branch/libstdc++-v3/include/bits/stl_tree.h
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/map/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/multimap/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/multiset/48101_neg.cc
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/set/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/unordered_map/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/unordered_multimap/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/unordered_multiset/48101_neg.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/23_containers/unordered_set/48101_neg.cc

[Bug libstdc++/85965] [8 Regression] G++ gives cryptic error instead of incomplete type

2019-04-02 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85965

Jonathan Wakely  changed:

   What|Removed |Added

Summary|[8/9 Regression] G++ gives  |[8 Regression] G++ gives
   |cryptic error instead of|cryptic error instead of
   |incomplete type |incomplete type

--- Comment #7 from Jonathan Wakely  ---
This is fixed on trunk now, but still needs to be backported to gcc-8-branch.