From: David Malcolm <dmalcolm@redhat.com>
To: Jonathan Wakely <jwakely@redhat.com>
Cc: Jason Merrill <jason@redhat.com>,
gcc-patches@gcc.gnu.org, Nathan Sidwell <nathan@acm.org>
Subject: Re: [PATCH 1/2] PR c++/91436 fix C++ dialect for std::make_unique fix-it hint
Date: Wed, 14 Aug 2019 17:58:00 -0000 [thread overview]
Message-ID: <1565804880.4994.4.camel@redhat.com> (raw)
In-Reply-To: <20190814155321.GL9487@redhat.com>
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
prev parent reply other threads:[~2019-08-14 17:48 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-13 13:39 Jonathan Wakely
2019-08-13 13:43 ` [PATCH 2/2] Add more entries to the C++ get_std_name_hint array Jonathan Wakely
2019-08-13 20:44 ` Jason Merrill
2019-08-14 10:50 ` Jonathan Wakely
2019-08-13 20:20 ` [PATCH 1/2] PR c++/91436 fix C++ dialect for std::make_unique fix-it hint Jason Merrill
2019-08-14 11:16 ` Jonathan Wakely
2019-08-14 14:40 ` Jason Merrill
2019-08-14 14:42 ` David Malcolm
2019-08-14 15:06 ` Jason Merrill
2019-08-14 16:02 ` Jonathan Wakely
2019-08-14 17:58 ` David Malcolm [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1565804880.4994.4.camel@redhat.com \
--to=dmalcolm@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jason@redhat.com \
--cc=jwakely@redhat.com \
--cc=nathan@acm.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).