From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10533 invoked by alias); 20 Apr 2009 16:17:19 -0000 Received: (qmail 10514 invoked by uid 22791); 20 Apr 2009 16:17:15 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-bw0-f176.google.com (HELO mail-bw0-f176.google.com) (209.85.218.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 20 Apr 2009 16:17:10 +0000 Received: by bwz24 with SMTP id 24so888535bwz.8 for ; Mon, 20 Apr 2009 09:17:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.120.193 with SMTP id e1mr5513046bkr.147.1240244223161; Mon, 20 Apr 2009 09:17:03 -0700 (PDT) In-Reply-To: <49EC9148.9070806@codesourcery.com> References: <6c33472e0808281543w5d464fe6r1fa5e584797ac46c@mail.gmail.com> <6c33472e0808281700m457e1f2euf6a0da108dd5b84a@mail.gmail.com> <6c33472e0810221705u1286ac46g166ec57677fe0f4c@mail.gmail.com> <6c33472e0904101212j69a8aa48hb12369c0aeb55242@mail.gmail.com> <6c33472e0904190416g1bff083j5a2a6e73640364f7@mail.gmail.com> <49EBED41.6070609@codesourcery.com> <6c33472e0904200138n73a3a3c6l779fc89d0fcff39f@mail.gmail.com> <49EC9148.9070806@codesourcery.com> Date: Mon, 20 Apr 2009 16:17:00 -0000 Message-ID: <6c33472e0904200917q221b7e76hd4aeedfe164b8f4e@mail.gmail.com> Subject: Re: [C/C++] PR 13358 long long and C++ do not mix well From: =?ISO-8859-1?Q?Manuel_L=F3pez=2DIb=E1=F1ez?= To: Mark Mitchell Cc: Gcc Patch List , Jason Merrill , Nathan Sidwell , Janis Johnson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2009-04/txt/msg01566.txt.bz2 2009/4/20 Mark Mitchell : > Manuel L=F3pez-Ib=E1=F1ez wrote: > > which matches anything, and which I agree is sloppy (though I added > plenty such tests over the years) and putting the entire text there. > It's generally possible to pick out a few key words from the error > message ("invalid overload" or "does not match" or "private" or some > such) that are the important part of the error message. > If one changes a message and there are not testsuite changes, then one cannot know whether this message is actually ever tested. If no testcase is added, then the feature may go untested. If one adds another testcase, then we may have two equivalent testcases for the same thing. The latter happens already in the g++.dg and g++.old-deja dirs. If there is one important keyword only, your proposal is reasonable but if there are several important keywords, then the choices are to use "\[^\n\]*", which is ugly to read and awful to search/replace, or use "|", which matches more than we want to match. For example, if you look at this pattern: - i =3D 18446744073709551615; /* { dg-warning "decimal constant|unsigned" "decimal constant" } */ you cannot tell which error message is matched. In fact, it turns out that there are two messages for this line: + i =3D 18446744073709551615; /* { dg-warning "integer constant is so large that it is unsigned" "decimal constant" } */ + /* { dg-warning "this decimal constant would be unsigned in ISO C90" "decimal constant" { target *-*-* } 28 } */ One mentions C90 (but it will still pass if it mentioned C++ or C++0x or pascal) and the other not. In this case, probably the first message is redundant but if it were important, we can lose it and it will never be noticed. We could also lose the second message and the test will still pass. On the other hand, perhaps the intention was to match only the second message and the redundant one may have appeared without anyone noticing. Moreover, I just noticed that in the g++ testcase I am using: + x1 =3D 0x1b27da572ef3cd86LL; // { dg-warning "long long" } which is not actually testing that CPP is printing: warning: use of C++0x long long integer constant instead of: warning: use of C99 long long integer constant So this feature may regress in the future without anyone noticing. >> Nonetheless, you are the maintainer, so if you want me to cut the test >> pattern, tell me what I should match and I will update the patch. > > I'm not going to make you change a perfectly good patch just for this. > But, unless Jason/Nathan indicate otherwise, I'd appreciate it if for > future patches you take a more circumspect approach. OK, I'll try, less work for me. But if I err on the side of specificity rather than generality, feel free to ask for changes. Cheers, Manuel.