On Wed, 2019-08-14 at 16:53 +0100, Jonathan Wakely wrote: > On 14/08/19 10:39 -0400, David Malcolm wrote: > > On Wed, 2019-08-14 at 12:02 +0100, Jonathan Wakely wrote: > > > On 13/08/19 16:07 -0400, Jason Merrill wrote: > > > > On 8/13/19 9:32 AM, Jonathan Wakely wrote: > > > > > * g++.dg/lookup/missing-std-include-6.C: Don't check > > > > > make_unique in > > > > > test that runs for C++11. > > > > > > > > I'm not comfortable removing this test coverage > > > > entirely. Doesn't > > > > it > > > > give a useful diagnostic in C++11 mode as well? > > > > > > It does: > > > > > > mu.cc:3:15: error: 'make_unique' is not a member of 'std' > > > 3 | auto p = std::make_unique<int>(); > > > | ^~~~~~~~~~~ > > > mu.cc:3:15: note: 'std::make_unique' is only available from C++14 > > > onwards > > > mu.cc:3:27: error: expected primary-expression before 'int' > > > 3 | auto p = std::make_unique<int>(); > > > | ^~~ > > > > > > So we can add it to g++.dg/lookup/missing-std-include-8.C > > > instead, > > > which runs for c++98_only and checks for the "is only available > > > for" > > > cases. Here's a patch doing that. > > > > FWIW this eliminates the testing that when we do have C++14 > > onwards, > > that including <memory> is suggested. > > Do we really care? > > Are we testing that *every* entry in the array gives the right answer > for both missing-header and bad-std-option, or are we just testing a > subset of them to be sure the logic works as expected? > > Because if we're testing every entry then: > > 1) we're missing LOTS of tests, and > > 2) we're just as likely to test the wrong thing and not actually > catch > bugs (as was already happening for both make_unique and > complex_literals). > > > Maybe we need a C++14-onwards missing-std-include-* test, and to > > move > > the existing test there? (and to add the new test for before-C++- > > 14) > > We could, but is it worth it?
Fair enough. Dave
