From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108954 invoked by alias); 20 Mar 2015 17:50:58 -0000 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 Received: (qmail 108944 invoked by uid 89); 20 Mar 2015 17:50:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 20 Mar 2015 17:50:56 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-02.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1YZ14P-0001YA-ED from joseph_myers@mentor.com ; Fri, 20 Mar 2015 10:50:53 -0700 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-02.mgc.mentorg.com (137.202.0.106) with Microsoft SMTP Server id 14.3.224.2; Fri, 20 Mar 2015 17:50:52 +0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.82) (envelope-from ) id 1YZ14M-0006P9-NV; Fri, 20 Mar 2015 17:50:50 +0000 Date: Fri, 20 Mar 2015 17:50:00 -0000 From: Joseph Myers To: David Malcolm CC: Subject: Re: [PATCH, stage1] Better error recovery for merge-conflict markers In-Reply-To: <1426866606-65042-1-git-send-email-dmalcolm@redhat.com> Message-ID: References: <1426866606-65042-1-git-send-email-dmalcolm@redhat.com> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2015-03/txt/msg01103.txt.bz2 On Fri, 20 Mar 2015, David Malcolm wrote: > I believe that the presense of these markers in source code is almost > always a bug (are there any GCC frontends in which the markers are > parsable as something valid?) Well, obviously they are valid inside #if 0, strings (where you have a test, though not one at start of line "\ <<<<<<<") and comments (where you don't have a test). They are also valid when stringized: #define str(s) #s const char *s = str( <<<<<<< ); must be accepted. They are also valid in the expansion of a macro that doesn't get expanded. #define foo \ <<<<<<< That is, in general, the invalidity only occurs when preprocessing tokens are converted to tokens. In C++ (C++11 and later), >>>>>>> can also close a sequence of nested template argument lists, thanks to the rule about replacing >> by > > in that context. And of course it's OK, if odd, to put that at the start of a line. So in that case the preprocessing tokens do get converted to tokens, and that token sequence (interpreted as >> >> >> > and then contextually adjusted to > > > > > > >) is valid. -- Joseph S. Myers joseph@codesourcery.com